Selecting internal team members when implementing an ERP system 2012

- II -II
Dissertation Task 4 1039030
Department of Information Systems and Computing
MTech Business Systems Integration with SAP Technology
Academic Year 2011-2012
Selecting internal team members when implementing an ERP system
Trond Jarnes - 1039030
A report submitted in partial fulfilment of the requirement for the degree of Master of
Technology
Brunel University
Department of Information Systems and Computing
Uxbridge, Middlesex UB8 3PH
United Kingdom
Tel: +44 (0) 1895 203397
Fax: +44 (0) 1895 251686

- III -III
ABSTRACT
The purpose of this Master thesis was to investigate how Norwegian companies
select their internal human resources for an Enterprise Resource Planning (ERP)
system implementation project, which skills where favoured and whether they took
into consideration the composition of the implementation team. It also investigated
whether they followed any of the recommendations found in literature and past
research. A great deal is written on the psychological fit between team members, the
importance of selecting the right employees, which skills they should possess and
the importance of the implementation team’s composition. There is also suggested a
need to formalise the selection process. With all this in mind, the research community
was lacking focus on combining all these critical factors and on summarising how to
best select the team members for an ERP implementation project.
By conducting three case studies, each in a Norwegian company/organization that
has implemented an ERP system, data was gathered using semi-structured
interviews. The project manager and two team members in each of the cases were
interviewed. Key findings from the case studies indicated that none of the three
project managers used a structured process when selecting team members for their
implementation team. Also, Team skills, Interpersonal skills, ERP technical
knowledge and technology management knowledge were not criteria for the team
members in any of the cases. All three projects faced some challenges making sure
the team members were freed from other time consuming responsibilities during the
whole project lifespan. One can also see that replacing team members can reduce
the collective knowledge of a team. Finally a list of recommendations is presented.
Some examples of these recommendations are; to use adequate time on building a
good internal implementation team before commencing the implementation, use a
structured selection process, use methods like the MBTI and the 8 Belbin roles to
help optimize the combinations of personalities and make sure the team members
are freed from other time consuming responsibilities outside of the project.

- IV -IV
ACKNOWLEDGEMENTS
First of all I would like to thank my supervisor Mr Eivind Brevik. He has been an
excellent supervisor and guide while writing this master thesis.
Secondly I would like to thank Maria Cristofoli at EVRY ASA. She gave me valuable
input when choosing the topic of this master thesis and she also helped me get in
touch with some of the case study companies.
I also want to thank my loving family for supporting me and taking an interest during
the extensive work on this master thesis.
Finally a special thanks to my loving girlfriend Inger.
.
TOTAL NUMBER OF WORDS:
11122

- V -V
TABLE OF CONTENTS
TABLE OF CONTENTS
TABLE OF CONTENTS V
CHAPTER 1 INTRODUCTION 1
1.1 RESEARCH AIM AND OBJECTIVES 2
1.2 RESEARCH APPROACH 3
1.3 DISSERTATION OUTLINE 3
CHAPTER 2 RESEARCH METHODOLOGY 4
2.1 QUALITATIVE RESEARCH 4
2.2 DATA COLLECTION 4
2.3 CASE STUDY 5
2.4 INTERVIEWS 5
2.5 SELECTION OF INTERVIEWEES 6
2.6 ETHICAL CONSIDERATION 6
2.7 DATA ANALYSIS 7
2.8 SUMMARY 7
CHAPTER 3 LITERATURE REVIEW 8
3.1 CATEGORISING AND SELECTING PEOPLE 8
3.2 ERP IMPLEMENTATION TEAMS 10
3.2.1 THE RIGHT PEOPLE FOR THE JOB 10
3.2.2 THE IMPLEMENTATION TEAM 11
3.2.3 THE SKILLS NEEDED 11
3.2.4 THE SELECTION PROCESS 13
3.3 SUMMARY 13
CHAPTER 4 CASE STUDY DESCRIPTIONS AND ANALYSIS 15
4.1 CASE STUDY 1 15
4.1.1 STRENGTHS 15
4.1.2 CHALLENGES 15
4.2 CASE STUDY 2 16
4.2.1 STRENGTHS 16
4.2.2 CHALLENGES 17
4.3 CASE STUDY 3 17
4.3.1 STRENGTHS 17
4.3.2 CHALLENGES 18
4.4 COMPARISON 18
4.4.1 SELECTION 19
4.4.2 SKILLS 20
4.4.3 TEAM 21
CHAPTER 5 DISCUSSION, KEY FINDINGS AND RECOMMENDATIONS 24
5.1 DISCUSSION 24
5.1.1 SELECTION 24
5.1.2 SKILLS 25

- VI -VI
5.1.3 TEAM 26
5.2 KEY FINDINGS 27
5.3 RECOMMENDATIONS 27
CHAPTER 6 CONCLUSION 30
6.1 CONCLUDING SUMMARY 30
6.2 RESEARCH CONTRIBUTIONS 30
6.3 LIMITATIONS 31
6.4 FUTURE RESEARCH 31
6.5 PERSONAL REFLECTIONS 32
REFERENCES 33

SELECTING INTERNAL TEAM MEMBERS WHEN IMPLEMENTING AN ERP SYSTEM
Page 1 of 32
CHAPTER 1 INTRODUCTION
The alignments of information systems (IS) and business functions have been a
popular issue for many decades. Ever since the beginning of the 1990s Enterprise
Resource Planning (ERP) systems have been used to achieve such alignment (Koh
et al., 2006). An ERP system is designed to support the entire company with all of its
business functions and needs (Woo, 2007). This means involving a high number of
employees from various departments when implementing such a system to assure
the best alignment. This makes an ERP implementation such a complex process and
a great challenge for all the people involved (Trimmer et al., 2002).
There is a general consensus in the research community that the technical aspects
of ERP systems have been well proven throughout the last decades (Chen, 2001).
Therefore todays’ research primarily focuses on which measures that should be
initiated before the actual adoption and implementation of an ERP system. Many
researchers have focused on identifying critical success factors involved with
implementing ERP systems, such as the importance of top management support,
project management, ERP teamwork, team composition etc. (Chen, 2001; Nah et al.,
2001; Bhatti, 2005; Bingi et al., 1999; Finney&Corbett, 2007). During the last decade,
a variety of researchers have stated that it is crucial to involve the best and brightest
employees within an organisation and obtain a good team composition when
implementing an ERP system (Chen, 2001; Nah et al., 2001; Bhatti, 2005;
Finney&Corbett, 2007; Woo, 2007). A variety of criteria for these employees, such as
having great technical, business, team and interpersonal skills are also stated in
literature and past research (Stratman&Roth, 2002). They need to be able to work in
cross-functional teams and to be freed from other time consuming responsibilities
during the implementation project (Nah et al., 2001). Also, the employees should be
selected to participate in the project by a formal set of guidelines to ensure that they
are suitable for the job (André et al., 2011; Kumar&M.P.Thapliyal, 2010).
As seen in chapter 3 (Literature Review) in this thesis, a great deal is written on the
psychological fit between team members, the importance of selecting the right
people, which skills they should possess and the importance of the team’s
composition. There is also suggested a need to formalise the selection process,
which can be achieved by e.g. using decision support systems. With all this in mind,
the research community was lacking focus on combining all these critical factors and
on summarising how to best select the team members for an ERP implementation
project (Patel, 2010). Based on these limitations this research project investigated

Page 2 of 32
how three Norwegian companies selected their employees when implementing their
current ERP system. The findings from this research project combined with literature
and past research resulted in recommendations on how to best select internal human
resources for an ERP implementation project in a Norwegian company.
1.1 Research aim and objectives
The aim of this research project was to investigate how Norwegian companies select
their internal human resources for an ERP implementation project, which skills where
favoured and whether they took into consideration the composition of the
implementation team. It also investigated whether they followed any of the
recommendations found in literature and past research. This research combined with
earlier findings resulted in recommendations for companies selecting internal human
resources for their ERP implementation project. It shows how employees have been
selected within three Norwegian companies in three different business areas. This again
will open for the possibility for a bigger and more quantitative research that statistically
can validate these trends and in that way further benefit academia. It will also be useful
within industry, since it will help companies to realize the impact of selecting internal
human resources and give them recommendations on how to do this.
Research question:
 How to select internal team members when implementing an ERP system?
Objectives:
 Conduct a literature review on the selection of human resources for a project.
 Conduct case studies with three Norwegian companies that have implemented
an ERP system in their organisation.
 Analyse the gathered data from the case studies to find out how the companies
selected employees for their project, which skills where favoured and to what
extent they took in to consideration the composition of the team.
 Compare findings from the case studies with literature and past research.
 Critically analyse and compare the objectives against the research question of
this research project.
 Make recommendations on how to select internal human resources for an ERP
implementation project on the basis of the findings from this research, literature
and past research
.

Page 3 of 32
1.2 Research approach
For this research project a qualitative research methodology has been followed. One
pilot study and three case studies have been conducted. Each of the studies focused on
a Norwegian company within one specific business area (aviation, renewable energy
and government) that have implemented an ERP system. Semi-structured interviews
were used to gather data from these companies. Project managers and team members
were interviewed to determine how employees were selected, which skills where
favoured and if they took into consideration the composition of the team. The data
gathered from the interviews were coded into three categories and structured into tables
to easier compare the findings to the literature and previous research. The findings were
discussed and essentially resulted in recommendations on how to select internal human
resources when implementing an ERP system in a Norwegian company.
1.3 Dissertation outline
The rest of this paper is structured as follows.
CHAPTER 2 Methodology: A presentation of the selected methodology for this research
project.
CHAPTER 3 Literature review: A literature review of methods for selecting people for
projects in general, and a range of past and current work related to the selection and
the importance of internal human resources in an ERP implementation project.
CHAPTER 4 Case study descriptions and analysis: An introduction to each of the case
studies and comparisons of the findings against the recommendations found in literature
and past research.
CHAPTER 5 Discussion, key findings and recommendations: A critical discussion of the
findings and recommendations on how to select internal human resources when
implementing an ERP system
CHAPTER 6 Conclusion: A summarised conclusion, the research contribution of the
thesis, its limitations, and some future research that can be conducted and personal
reflection of the author.

Page 4 of 32
CHAPTER 2 RESEARCH METHODOLOGY
This chapter presents and argues for the method, data collection and data analysis
used throughout the research. The chapter is divided into four parts. The first part
introduces the chosen research method, the second part explains how data is
collected, and the third part describes the data analysis process and finally the fourth
part summarizes the chapter.
2.1 Qualitative research
Qualitative and quantitative researches are both used within the social sciences.
Qualitative research offers a deeper insight on the subject than quantitative since it
investigates knowledge using focused methods like interviews, participant
observations or ethnographic studies etc. (Grix, 2004). The number of cases
analysed is naturally also less in number than in quantitative research. A researcher
hence get a closer relationship to the subjected persons involved in a qualitative
research project and therefore the ethical considerations are considered to be
greater compared to quantitative research. Critics of qualitative research often
question the validity of the data gathered, since it is hard to statistically generalize the
findings from small samples (Grix, 2004). Qualitative research is most commonly
used to gain information on a specific event, decision, geographical location or issue.
A qualitative approach often aims to prove trends, patterns or relationships between
variables etc. (Grix, 2004).
For this research project a qualitative rather than a quantitative approach is chosen
justified by the aim to investigate a specific process and to learn about the trends
regarding such a process within different companies in Norway. This requires a deep
approach when collecting data rather than a broad and longitudinal approach like
most quantitative researches are. This approach also fit the timeframe of the
research project.
2.2 Data collection
The data collected in this research project stems from both primary and secondary
research. Data is gathered from interviews (primary), third party research and
literature (secondary). Interviews of employees involved in the implementation project
were used to gather data on how people where selected to contribute to the project.
Third party research and literature were used to gain knowledge on the skills needed
by people in an ERP implementation and methods for selecting people for jobs,
projects etc.

Page 5 of 32
2.3 Case study
The Case study method is most commonly used as a qualitative research method
that investigates individuals, organisations, processes, programs, neighbourhoods,
institutions, events etc. (Yin, 2009). Case study research can use both single and
multiple-case studies (Yin, 2009). Single-case studies are often used when
investigating a unique or critical case that cannot be compared with or supported by
other cases. The critics of single-case study design are sceptical to the validity of the
findings when only one case has been investigated (Grix, 2004; Yin, 2009).
Therefore extremely strong arguments are required to choose a single-case design.
On the other hand, using multiple-cases diminishes, to some extent, the criticism and
scepticism related to the validity of the single-case design (Yin, 2009). When using
multiple-case studies, independent cases are investigated separately to finally
contribute to one joint conclusion in the end. Another argument for doing multiple
case studies is to increase the understanding and explanation of a subject
(Miles&Huberman, 1994). The multiple case studies makes it easier to determine
under which condition the findings of the research occur (Miles&Huberman, 1994).
In this research project a multiple-case study design was used. A pilot study was
conducted before the actual case studies to test the questions and see how a person
would react to them. Further the three case studies were conducted to strengthen the
validity of the research, because the analytical benefits from using two or more cases
could be of significant (Yin, 2009). Each case focuses on a company in Norway
within one specific business area that have implemented an ERP system in their
organisation.
2.4 Interviews
A semi-structured interview is a popular method of interviewing since it gives the
interviewer a great deal of flexibility (Grix, 2004). The interviewer uses around 10
predefined questions during the questioning. These questions do not have to be
asked in a specific order and additional questions can be added during the interview.
This provides the interviewer the possibility to gain more insight into the participants’
knowledge and gives the interview a calmer and more natural touch (Grix, 2004).
The semi-structured interview method is used in this research project because it
gives flexibility when conducting the interviews. There are two sets of interviews, one
for the project managers and one for the team members. Since the interviews are
semi-structured it is possible to add additional questions to the seven predefined
questions during an interview. The questions are categorized into the following three

Page 6 of 32
groups; Selection, Team and Skills. This is to easier link the gathered data to
previous research and literature. During an interview the questions can be asked in a
random order regardless of which group they belong to.
2.5 Selection of interviewees
Both project managers and regular team members (system users) were interviewed.
This was done to find out how the implementation teams were constructed and if the
recommendations found in literature and past research was taken into consideration
within in the three cases. The aim of interviewing the managers was to investigate
how they selected their team members for their implementation project, what criteria
they considered for their candidates and how they viewed the success of their
implementation team. The interviews with the team members focused on
investigating how they experienced the rest of the team and how it performed in
relation to the skills and knowledge that is required for an ERP implementation.
Interviewing the team members also worked as a reference/challenge to what the
project managers answered.
Because of the lack of available people across the three case studies, only two team
members were interviewed in each company. Although this was below the
representable selection that was desired it still gave an indication on how the team
members was selected and how the teams functioned.
2.6 Ethical consideration
The people involved in this research project are the academic supervisors, the
project managers and the project team members from each of the three case study
companies that have been subjected to my interviews. The participants from the case
studies needed to be interviewed to learn how the selection process, of internal
human resources for an ERP implementation project, was conducted in three
Norwegian organisations. The specific data gathered by the interviews, the personal
information of the interview objects and the name of the case study companies are
confidential and therefore will not be disclosed to anyone except the academic
supervisors. The participant’s received an information sheet that described the
research project and its intent. Each participant filled out a consent form regarding
their participation and they also had the option to withdraw their contributed
information at any time during the research project. Dr. Laurce Brooks, Chair of the
Research Ethics Committee, approved the standard Ethics application form
(Appendix A) from Brunel University.

Page 7 of 32
2.7 Data analysis
There is no one right way to analyse qualitative data (Coffey&Atkinson, 1996). This is
because there are many different types of qualitative data which require many
different ways of analysing (Coffey&Atkinson, 1996). Since this research project is of
a qualitative nature, using case studies and semi-structured interviews, the data will
be soft (words and images from documents and observations) (Grix, 2004). The data
are coded into the following three groups; Selection, Skills and Team. These groups
are formed on the basis of literature and previous research regarding employee
selection and team building. The data was structured into tables, which made it
easier to compare the findings from the interviews to the literature and previous
research. The findings were discussed and essentially resulted in some
recommendations on how to select internal human resources when implementing an
ERP system in a Norwegian company.
2.8 Summary
This research project is based on a qualitative approach using three case studies,
and the data is gathered by using semi-structured interviews. The data is confidential
and will be coded into three groups (Selection, Skills and Team), selected based on
literature and previous research, and structured into tables making it easier to
analyse. The following chapter (3) will consist of a literature review.

Page 8 of 32
CHAPTER 3 LITERATURE REVIEW
This chapter introduces past and current literature and research on project teams
and information on how to build them. The first part of this chapter will focus on how
to categorise and select people. The second part deals with ERP implementation
teams and what is important when forming such teams.
3.1 Categorising and selecting people
Despite the developments done within the field of project management, managing
human resources still remains a great challenge (Otero&Otero, 2012). Involving
people into teams is critical for a projects success (de Korvin et al., 2002). Project
managers therefore need to select the right people to make sure that the objectives
of the project will be filled (de Korvin et al., 2002). Selecting the right kind of people is
often difficult, whether it is to fill a position for a job or to put together a project team.
Managers and psychologists have developed many different tests to help understand
and categorize people. These tests have been used for hiring people, assigning them
to different jobs, projects and other similar assessments (Frame, 1995).
The Myers-Briggs Type Indicator (MBTI) is one example of a psychological test that
is used in conjunction with selecting the right people for a technical project (Frame,
1995). It consists of a number of tests to determine a person’s psychological type.
This method is based on work of the famous Swiss psychologist Carl Jung. In 1923
he published a work describing different psychological types. The MBTI method
categorises people using four scales; extravert-introvert, sensing-intuitive, thinking-
feeling, and judging-perceiving. Depending on where a person fits in the different
scales he/she will match one out of sixteen different psychological types (Frame,
1995). Using the MBTI characteristics have been proven to have a major effect on
the success of a IT-project since personality plays a considerable role in a team
based project (Peslak, 2006). Based on the MBTI method, recommendations on
creating optimal software teams have been made (Gorla&Lam, 2004). The
recommendations regarding personalities are listed in Table 1 below.

Page 9 of 32
Recommendations for creating an optimal software team
Personality
heterogeneity
Select personnel so there is personality heterogeneity between the team
leader and other team members in the social-interaction and
information-gathering dimensions. All of the four of these personality
categories should be represented: extrovert-intuitive, extrovert-sensing,
introvert-intuitive, and introvert-sensing.
Diversity of
personalities
It is unnecessary to have diversity of personalities among team members
(excluding team leader) due to the fact that members need to perform
multiple tasks of the system development life cycle (SDLC) and
heterogeneity is not good for all phases. This should give IS managers
the flexibility needed to select members of appropriate personality,
although it may be difficult for small businesses with limited resources
to find desired personnel.
Team leader
Select the team leader such that he or she is of intuitive (N) type on the
information- gathering dimension, since such a team leader will be able
to visualize future information requirements better. The optimal
personality for a team leader in the decision-making dimension is a
feeling (F) type. The preferred personality type in the dimension
involving dealing with external world is judging (J), since it is important
for the team leader to establish project milestones and make sure other
members follow them.
Team
member
The optimal team member personality for dealing with the external
world dimension is judging (J), since this attribute will help them meet
project deadlines.
Systems
analyst
The optimal personality for a systems analyst in the decision-making
dimension is thinking (T), because a thinking person will use a scientific
approach and base decisions on logical reasoning. A sensing (S) type
system analyst is optimal regarding the information gathering
dimension, since heterogeneity between the personalities of the team
leader and team members on the information gathering dimension is
desired and an intuitive team leader is preferred. The practical
orientation of a sensing type will be helpful in providing detailed design
and programming specifications and participating in programming tasks.
Programmers
The preferred personality for programmers on small teams is extroverted
(E). An extrovert can communicate easily with other participants in
system development. As with other team members, the desired
personality types for a programmer are sensing (S) on the information-
gathering dimension and judging (J) on the dimension involving dealing
with the external world.
Table 1 Recommendations for creating an optimal software team (Gorla&Lam, 2004)
According to the recommendations above, psychological tests like the MBTI may
help managers combine personalities that work well together in a project. However,
one of the problems when using the MBTI method, is that it does not measure
intelligence, drive, or technical competence (Frame, 1995). It only shows a manager
the psychological type, which although it will give him/her the ability to get a better
psychological equality between the people in a project, it will not be enough if the
project is of a technical nature (Frame, 1995).
The work of Meredith Belbin is also used when selecting people for a project
(Cadle&Yeates, 2008). Belbin discovered there are eight “team roles” that are
necessary in a project. These roles are Coordinator, Shaper, Innovator, Resource
Investigator, Monitor/Evaluator, Team Worker, Implementer and Completer. When all

Page 10 of 32
these roles are filled, the team is more likely to succeed (Cadle&Yeates, 2008).
Belbin’s method could be a helpful tool for managers to avoid selecting team
members of only one kind (Cadle&Yeates, 2008).
3.2 ERP implementation teams
The technical aspect of ERP implementation has been well proven throughout the
last decades, today it is more commonly to focus on what needs to be done before
the actual adoption and implementation (Chen, 2001). This involves all planning
issues related to ERP implementations and the different important steps of the
planning process, like choosing the “right” ERP system, involving the right people,
matching business processes with the chosen system, understanding the
organisational requirements and also economic and strategic justification (Chen,
2001). During the last decade, a variety of researchers (Chen, 2001; Nah et al.,
2001; Bhatti, 2005) have stated that it is crucial to involve the best employees within
an organisation and obtain a good team composition when implementing an ERP
system. A variety of criteria for these employees are also prepared in literature and
past research. Therefore, this section will focus on the importance of involving the
right people in an ERP project, which skills are required of the team members, the
composition of the team and essentially how one can ensure that the most
appropriate employees will be selected.
3.2.1 The right people for the job
Selecting employees to be involved in an ERP implementation project requires the
right employees with both technical and business knowledge (Stratman&Roth, 2002;
Gorla&Lam, 2004; Woo, 2007). It is also important that the employees involved in an
ERP implementation project understand the organisational requirements. This
requires that the top management identifies the best people in the organisation,
make them commit to the project and free them from other time consuming
responsibilities during the implementation (Chen, 2001; Nah et al., 2001; Bingi et al.,
1999; Chen&Small, 1996; Finney&Corbett, 2007). Companies seldom realize the
importance of involving the right kind of employees in an ERP implementation project
therefore the importance of this aspect cannot be overemphasized (Bingi et al.,
1999). A lack of understanding of the needs of the project and not being able to help
guide the project is a major reason for failure of an implementation project (Bingi et
al., 1999). According to a survey, made by Jeff Stratman and Roth, having competent
members of the ERP team ranked fourth on the most important success factors for IS
implementations (Bhatti, 2005). In addition in a list over issues regarding ERP

Page 11 of 32
implementations made in 2010, the selection of the right employees to involve in an
implementation project was one of the main points (Kumar&M.P.Thapliyal, 2010).
3.2.2 The implementation team
The team members’ commitment to an ERP implementation project is important and
involves spending a significant amount of time on administrative tasks like serving on
the steering or executive committee managing the implementation (Chen, 2001).
Teamwork and composition of the implementation team is also often declared as
critical success factors since they are important throughout the whole ERP life cycle
(Nah et al., 2001). It is also important to focus on building cross-functional teams
which hold both technical and business knowledge to achieve success (Nah et al.,
2001; Woo, 2007). These teams should also, as far as possible, be co-located to
make it easier for the team members to work together (Nah et al., 2001). The team
should be balanced and consist of a mixture of internal and external resources
(Bhatti, 2005). Internal employees involved in the project should especially possess
great knowledge in the needs of the company and its business processes
(Kumar&M.P.Thapliyal, 2010; Bingi et al., 1999; Gorla&Lam, 2004).
3.2.3 The skills needed
ERP systems constantly evolve and therefore require an updated set of skills
(Mohamed&McLaren, 2009). Due to the lack of people with ERP skills in the late
1990s, university business schools started to include ERP in their curriculum. In
relation to this, Boyle and Strong (Mohamed&McLaren, 2009) joined past studies
with their own survey-based research to categorize the key ERP skills required by
university graduates. This resulted in 32 skills divided into five categories illustrated
in Table 2 below.

Page 12 of 32
Key ERP skills required by university graduates
ERP technical knowledge
 ERP Administration
 Networks
 Operating systems
 Systems Analysis
 Systems Design/Integration
 Systems Life Cycle Management
 Relational Databases
 ERP related programming
language
 Data Management
 Decision Support Systems
Technology management knowledge
 Knowledge of ERP Concepts
 Ability to learn new technologies
 Ability to focus on technology as
a means, not an end
 Ability to understand
technological trends
Business functional knowledge
 Knowledge of Business
Functions
 Willingness to learn in detail a
specific business functional area
 Ability to quickly understand the
needs of customers
 Ability to understand the business
environment
 Ability to interpret business
problems
 Ability to develop appropriate
technical solutions to business
problems.
Interpersonal skills
 Ability to deal with uncertainty
 Ability to accomplish
assignments Ability to write
coherently
 Ability to learn
 Ability to deliver effective
presentations Ability to be
proactive
 Ability to be sensitive to
organisational culture
 Ability to teach others
Team skills
 Ability to work cooperatively in a
team environment
 Understanding of group dynamics
 Ability to plan projects
 Ability to lead projects
Table 2 Required ERP Skills for ERP Education (Mohamed&McLaren, 2009)
These skills should to some extent be applicable for team members in an
implementation project. In addition, eight important competency constructs for those
working with an ERP system have been identified by doing a cross-disciplinary
literature review, followed by structured and unstructured interviews of various roles
involved in an ERP system (Stratman&Roth, 2002). These constructs are divided into

Page 13 of 32
“Technical & Managerial elements” and “Organisational elements” as shown in Table
3 below.
Technical & Managerial
Elements
Organisational Elements
Strategic IT Planning Business Process Skills
Executive Commitment ERP training
Project Management Learning
IT Skills Change readiness
Table 3 Theoretical framework linking ERP competence constructs and performance (Stratman&Roth,
2002)
The ability to handle greater responsibility when working on the project is another
important capacity (Muscatello&Chen, 2008). Unintended consequences may occur if
an employee has an emotional fallout due to greater responsibility than normal
(Muscatello&Chen, 2008). This section shows there are many skills related to ERP
systems mentioned in literature and past research even though managers sometimes
fail to acknowledge the skills required of their employees when implementing an ERP
system (Muscatello&Chen, 2008).
3.2.4 The selection process
The lack of proper system understanding and the ability to provide leadership for the
project team is a major reason for ERP implementation failure
(Kumar&M.P.Thapliyal, 2010). This has been discussed continuously in past
literature and research. During the last few years researchers have begun
emphasising the need to follow formal guidelines when selecting internal human
resources for a technical project (Kumar&M.P.Thapliyal, 2010). That indicates that
research on the topic of internal human resources has evolved from simply stating
the importance of involving employees and which skillset they should possess, to
discuss how they should be selected. People are often assigned to projects based on
how the project leaders experience with them in the past, their availability and their
skills (André et al., 2011). A large organisation with a high number of employees
often contain several possible candidates for a project (André et al., 2011). To pick
the right candidates to participate in a project, could therefore be as good as
impossible without help from some kind of decision support system (André et al.,
2011).
3.3 Summary
In this chapter past and current literature and research on project teams have been
presented. As can be seen, it has been written about the psychological interaction
between team members, the importance of selecting the right people, which skills
they should possess and the importance of the team’s composition. In recent years it

Page 14 of 32
has also been identified a need to formalise the selection process, which can be
achieved by using decision support systems. The following chapter (4) will introduce
the case studies and an analysis of the gathered data.

Page 15 of 32
CHAPTER 4 CASE STUDY DESCRIPTIONS AND ANALYSIS
This chapter describes the three case studies regarding both strengths and
challenges. The answers from the interviews in each company was collected in a
table and compared to recommendations presented in literature and past research.
The comparison is presented in the last section of this chapter.
4.1 Case study 1
The first case study (C1) presents a company developing communication technology
for commercial air travel. In 2009 they started to implement a new ERP system from
Microsoft called Dynamix AX. This system went live in March 2011. Their
implementation project team consisted of employees representing every division of
the company allocated across two Norwegian cities. Overall their implementation
project is seen as a success, meaning it was finished fairly within time and budget.
4.1.1Strengths
By comparing the interviews conducted with the project manager and the two project
members in C1, a couple of strengths are identified (Table 4). The project manager
focused on company experience and cross-functionality when building the
implementation team. This led to all-over satisfying collective company knowledge
within the team. According to the two project members this was the situation at the
beginning of the project, until people was taken off the project for different reasons.
This resulted in a loss of knowledge in the team in general.
Table 4 Strengths in C1
4.1.2Challenges
In the same way that the strengths were identified there was also identified some
problems (Table 5). Some employees embraced the increased responsibility;
however some struggled with it and were essentially replaced, according to the
project manager. The project manager also said there was a generally good support
among the team members. Still some people had some motivation problems and in a
few cases members were slowly phased out of the project because of their negative
attitude.
Every project member logged hours to make sure the workload was evenly balanced
between the project and other responsibilities. Despite this action, both of the
interviewed team members claimed they had too much work to do in certain periods
Category Strengths
Skills A cross-functional team.
Good knowledge at first.

Page 16 of 32
of the project and they did not always get freed from other time-consuming
responsibilities.
One of the team members experienced difficulties with the combination of different
personalities in the team. He/she experienced that not everybody was willing to
discuss issues regarding the business. Some even kept issues hidden from other
members of the team, which eventually led to a lot of extra work.
According to the team members, knowledge within the project team was eventually
reduced due to members being replaced.
Category Challenges
Selection No formal guidelines
Skills Lost some knowledge when members got replaced
Team
Some struggled with increased responsibilities and in
some cases had to be replaced.
Had to replace some team members because of negative
attitude.
Team members claim that they had too much work to do
in certain periods.
Some problems with different personalities.
Table 5 Challenges in C1
4.2 Case study 2
The second case study (C2) is based on a Norwegian renewable energy company.
They first implemented SAP’ ERP system called R3 which went live in the last
quarter of 2002. In the following years they have continued to build and expand the
functionality of their ERP system. One of these expansions contained a replacement
of their maintenance system, so in 2009 they started a project called MainSAP. This
project has been the focus of C2. Their implementation project team consisted of
employees representing the maintenance department in the company. This
implementation project has been considered a success.
4.2.1Strengths
By comparing the interviews, conducted with the project manager and the two team
members in C2, a couple of strengths are identified (Table 6). The team members
expressed there was a good access to knowledge within the team. There also
existed a good dialogue between the team members. This project needed a high
number of contributors, which resulted in a large team with a broad experience.
People were sincerely dedicated, motivated and solution oriented according to the
two team members. The project manager concluded it was undoubted a positive
experience to lead the project and he said the team coped very well with increased
responsibilities.

Page 17 of 32
Category Strengths
Skills
Good access to knowledge.
Dialog with other people.
Team
A large team with broad experience.
People were dedicated, had good motivation and solution
oriented.
People coped very well with increased responsibilities.
4.2.2Challenges
The project in C2 seems to have been carried out without much complication.
Nevertheless there are some minor problems that can be mentioned (Table 7). One
of the team members experienced some challenges related to the combination of
different personalities. There were different opinions on how processes actually were
related and this led to some difficulties. At the beginning of the project they showed a
good ability to manage their time, which resulted in an exactable workload. However,
later on in the project a time squeeze appeared and sometimes the amount of work
was way too big according to the two team members.
Category Challenges
Team
Some challenges regarding different personalities resulting in different shades of
opinion regarding how things actually are related.
Sometimes it became too much work.
At the beginning of the project, we were perhaps better to manage our time. But
later on there was a bit of a time squeeze
4.3 Case study 3
The third case study (C3) is based on a Norwegian municipality. They replaced their
self-developed legacy systems with an ERP system called Agresso Business World
from the Dutch software company Unit4 in 2008. The project in C3 focuses on the
implementation of the payroll and human resource (HR) module of the system.
The project team consisted of 15 employees from different departments such as
procurement, legal, document, IT, payroll and finance.
4.3.1Strengths
By comparing the interviews, conducted with the project manager and the two project
members in C3, a couple of strengths are identified (Table 8). The project in C3 is the
only project in the thesis that has used temporary employment (temp) to lighten the
workload for some of the project members. When employees struggled with
increased responsibilities, the project manager made sure they got assistance from
other members in the team.

Page 18 of 32
Category Strengths
Team
Used temps to lighten the workload of some project members.
People that struggled with increased responsibilities got backup.
Nobody had to be replaced.
4.3.2 Challenges
The project in C3 also had some challenges (Table 9). One of the team members
said in the interview that the team lacked some business knowledge and that they
were too few. The project manager reported that there was no deliberate focus on
cross-functionality when the team was put together. Despite bringing in temps to
lighten the workload for some of the project members, both of the interviewed
members reported there had been times where they struggled with to high workload.
Both the project manager and one of the team members said there was some lack of
support in the beginning of the project because some did not see the value of a new
system.
Category Challenges
Skills
Too few people involved.
Lacking knowledge in the team.
No focus on cross-functionality
Team
Struggled a bit with the support at first.
Struggled with to high workloads
4.4 Comparison
As seen in chapter 3 (Literature review) there are various recommendations exciting
on selecting people for ERP implementation projects and IS projects in general. In
the following sections the findings from the three case studies will be compared to
these recommendations. The recommendations are categorised into the following
three groups Selection, Skills and Team. The Selection category consists of
recommendations regarding the need for structural selection process with formal
guidelines. The Skills category consists of recommendations saying the team
members should possess ERP technical knowledge, technology management
knowledge, business functional knowledge, interpersonal skills, team skills and that
the team should be overlapping and cross-functional. The Team category consists of
recommendations suggesting the team members should be supportive of the project,
cope with increased responsibilities, freed from other time consuming responsibilities
and that the team should consist of a good combination of personalities.

Page 19 of 32
4.4.1Selection
Kumar & M.P.Thapliyal expressed the need of formal guidelines when selecting
employees for a technical project (Kumar&M.P.Thapliyal, 2010). This is because, as
mentioned in chapter 3, proper system understanding and the ability to provide
leadership for the project team is a major reason for ERP implementation failure. The
comparison between the findings from the case studies and the recommendations
regarding selection of human resources found in literature and past research are
presented in table 10 below. In all three cases the team members were selected
based primarily on their business experience. The project manager in C2 mentioned
he also emphasized to some extent his professional experience with each employee.
One project member in C3 was involved in the project partly because of prior system
experience. According to this none of the three project managers followed the
recommendation from Kumar & M.P. Thapliyal to use a structured selection process
instead they used discretion. André et al. stated that choosing the right candidate to
be involved in a project could be impossible in a large organisation without some kind
of decision support system to rely. The comparison between the findings from the
case studies and the recommendations regarding skills found in literature and past
research are presented in table 10 below. The organisation in C1 consists of less
than 150 employees, which should make it possible to get a general overview of all
the candidates without having to use a decision support system. This was also the
situation in C3; according to the project manager they involved 15 out of 25 potential
employees in their implementation project. Despite the “small” organisation, the
project manager expressed he would have spent more time on building the team and
used a more structured selection process if they were to start all over again. In C2 on
the other hand, the organisation consists of about 3400 employees overall. This
could pose a problem when the aim is to involve the best and brightest people in the
organisation. Despite this large organisation the project manager seemed to be very
pleased with his implementation team and its effort. He also mentioned after the
interview that he would have used a more structured selection process if they were to
start all over again. This, he explained, is because a more structured and formal
process would have led to a better documented process that would have been useful
next time a project team is to be put together. The comparison between the cases
and the literature is presented in Table 10 below.

Page 20 of 32
Category: Selection
Recommendations from literature Case
Answered by Project
Manager Answered by Team members
Structured selection process, Formal
guidelines
1
Not formal, based on
experience
Based on experience
2
Selection on the basis of the
candidates experience and
my experience with them.
We used the project scope to
figure out whom we needed
in the project.
Knowledge, and showed
initiative.
3
No formal guidelines. Based
on business knowledge.
Based on business knowledge
and some system understanding
Table 10 Selection comparison
4.4.2Skills
Selecting the best and brightest employees with both technical and business
knowledge is necessary when implementing an ERP system. It is also important that
the team members understand the organisations business requirements and that the
team is cross-functional. The comparison between the findings from the case studies
and the recommendations regarding skills found in literature and past research are
presented in Table 11 below.
As mentioned earlier, the project managers in all three cases focused primarily on
business functional skills when selecting their team members. This means the
following skills found in literature were not taken into consideration when they
selected their team members; ERP technical knowledge, Technology management
knowledge, Interpersonal skills and Team skills. One of the team members in C1
stated their team lacked knowledge in relation to carry out such a project and which
knowledge that should be exciting before starting the implementation. Of all the team
members in the three cases, only one team member in C1 felt it was unnecessary to
double check issues with other members because he/she had an excellent
understanding of his/her area of expertise. All the other team members in all three
teams often double checked with colleagues before making a decision. A team
member in C2 also stated he/she sometimes triple checked to make sure he/she did
the right thing. The team in C2 was very cross-functional and had a lot of knowledge
within the project and they also had a good dialogue. In C1 they started out with
having a lot of knowledge within the team, but this changed when they had to replace
some of the team members due to different reasons. In C3 one of the project
members stated the team lacked some business understanding. The comparison
between the cases and the literature is presented in Table 9 below.

Page 21 of 32
Category: Skills
Answered by Project
Manager
Answered by Team
members
ERP technical knowledge, Technology
management knowledge, Business
functional knowledge, Interpersonal
skills and team skills. Cross-functional.
1
Only business. Cross-functional Good business knowledge at
first but lost some knowledge
when members got replaced
2
Business technical skills and
some interpersonal skills
It was a very strong team! Good
access to knowledge. A lot of
dialog with other people.
3
Business skills. No focus on
cross-functional
Lacking knowledge in the team.
Table 11 Skills comparison
4.4.3 Team
The implementation team in itself is very important in a technical project. It is crucial
that the team members are positive and supportive of the team’s work and that they
can cope with increased responsibilities. It is also important that the team members
are freed from other time consuming responsibilities so they can commit to the team
and the work that it is set to do. The team should also consist of a good combination
of personalities and roles to assure a dynamic team. The comparison between the
findings from the case studies and the recommendations regarding the team found in
literature and past research are presented in table 12 below.
In C1 the project manager reported overall good and supportive attitudes throughout
the project’s lifespan. However there were a few team members that talked
somewhat negative about the project, but they were slowly phased out to prevent
them from poisoning the rest of the team. The project manager and both of the team
members that was interviewed in C2 claimed all of the team members were
supportive and dedicated to the project. In C3 they had some resistance at first
because some of the team members did not see the value of a new system. This
eventually changed during the project.
The project manager in C1 said some of the team members handled increased
responsibilities, some struggled and a few eventually had to be replaced because
they could not handle it. In C2 the team members all handled increased
responsibilities, and the project manager pointed at interesting tasks as the reason
for this. Some of the team members in C3 also struggled with increasing
responsibilities. It was arranged so that these team members got assistance from
colleagues to help them handle the responsibility. This way no team members had to
be replaced.
As mentioned earlier, the team members in C1 logged hours to help balance the

Page 22 of 32
workload between daily work tasks and the project tasks. Despite this, the workload
sometimes became too heavy and only some of the team members were freed from
other time consuming responsibilities. Both team members reported that non-project
related tasks sometimes got in the way of their responsibilities in the project. Also
some team members in C2 were freed from other time consuming responsibilities.
These members had the project as their first priority. Despite this, other non-project
related tasks became time consuming after a while and the participants experienced
a time squeeze. In C3 temporary employees was brought in to lighten the workload
for the employees that was involved in the implementation project. Despite this action
some of the team members felt they had too much work to do in certain periods of
the project and one of the interviewed team members meant there were too few
people involved in the project. One of the team members said other responsibilities
sometimes got in the way of the project.
Having a good combination of personalities in the team was not considered in any of
the three cases. This means that methods like the MBTI or the 8 Belbin roles were
not used in any of the cases.
One of the team members in C1 reported it sometimes was difficult to work with
some of the other team members because they chose to withhold information from
the rest of the team, which eventually resulted in some additional work. A team
member in C2 experienced some difficulties with different personalities in the team.
He/she stated that some team members had a different perception of how processes
in the business actually worked, which became a challenge. The team members in
C3 did not report any difficulties regarding personalities; the only concern was that
the average age was a bit too high. The comparison between the cases and the
literature is presented in Table 12 below.

Page 23 of 32
Category: Team
Answered by Project
Manager Answered by Team members
Freed from other time consuming
responsibilities, good combination of
personalities, supportive, cope with
increased responsibilities
1
To some degree freed from
other time consuming
responsibilities. Generally
good support but had to
replace some team
members. Some handled
increased responsibility and
some did not and had to be
pushed and in some cases
replaced
Some were freed from other time
consuming responsibilities
although sometimes it was too
much work. Some problems with
different personalities. Overall
good support/attitude.
2
To some extent the
personality, but mostly cross-
functionality. We had a large
team with broad experience.
We used the project scope to
figure out whom we needed
in the project. Some were
freed and had the project as
the 1st priority. Members
coped very well with
increased responsibilities.
The project was a positive
experience to work on the
project.
There were some challenges.
Different shades of opinion of
how things actually are related.
Some, not all were freed from
other time consuming
responsibilities. People were
dedicated, had good motivation
and solution oriented. Sometimes
it became too much work.
3
Some were freed from other
time consuming
responsibilities. Used temps
to lighten the workload for
some. Other colleagues
assisted those who struggled
with increased
responsibilities. The support
varied.
Too high average age. Some were
overworked. Other
responsibilities got in the way of
the project.
Table 12 Team comparison

Page 24 of 32
CHAPTER 5 DISCUSSION, KEY FINDINGS AND RECOMMENDATIONS
In this chapter the overall strengths and challenges, found in the three case studies,
and the comparison from chapter 4 are discussed. The final section presents
recommendations on how to select internal human resources for an ERP
implementation project.
5.1 Discussion
5.1.1Selection
As seen in chapter 4 the recommendations to use a structured selection process and
formal guidelines have not been used in any of the three cases. Since the number of
potential team members in C1 and C3 are relatively low there is a reasonable chance
that the project managers could get a good overview and select a good mix of
candidates without having to use a formal selection process. Despite not having an
overwhelming number of employees to choose from, the project manager in C1 had
to replace some of the team members during the project because they did not benefit
the project’s goal in an adequate matter. Therefore the project manager in C1 stated
he would have spent more time on a structural selection process if he were to start all
over again. This could have resulted in better interaction between the team members
and better assure that the team members really understood how the business
processes worked.
In C2 on the other hand the company consists of around 3500 employees, which
means there could be a lot of potential candidates to their project team. Despite the
possibility of many potential candidates the project manager in C2 was very pleased
with his selection, which was based on discretion and the candidate’s business
experience. Although the project manager in C2 was very pleased with his team, he
stated he would have used a more structured selection process if he were to build
such a team again. If he had taken a structured approach he could more easily have
documented the process, which he and his colleagues would have benefited from in
the future.
The project managers in all three cases used discretion with emphasis on the
candidates’ business experience when selecting their team members. Nevertheless
the project managers in C1 and C2 stated that if they had to start all over again they
would have taken a more structured approach when building their implementation
team. C1, which focused on a relative small organisation, compared to C2
experienced more challenges related to their team members. This points to a need
for a structured selection process within ERP projects also in smaller organisations.

Page 25 of 32
The project managers in C2 and C3 were very satisfied with their teams despite not
using a structured selection process. Notwithstanding, it is not certain this will be the
case the next time they conduct such a project. By leaving things up to chance and
not documenting their decisions for future reference, the possibility of ending up with
the optimal team is somewhat reduced. As the literature states, the safest thing to do
when selecting team members for an ERP implementation project is to dedicate
enough time to use a structured selection process, which will lead to a good
documented result and a thorough investigation of every possible candidate.
5.1.2Skills
Among all the different skills found in literature and past research it was primarily the
business functional knowledge that was emphasised in all three cases. The fact that
all three project managers focused on business functional knowledge is no surprise
since implementing an ERP system basically aims at aligning an Information System
with an organisations’ many business processes. In none of the three cases were
team skills, ERP technical knowledge and technology management knowledge a
criterion when selecting team members.
One of the team members in C1 reported he/she sometimes experienced that team
members was reluctant to collaborate and that they withheld information from the rest
of the team. This point to the lack of team skills. A team member in C2 stated a few
of the team members had a wrong perception of how business processes actually
worked. This was a challenge and led to the decision to cut some aspects of the
project because they did not follow the original plan. This point to the lack of business
functional knowledge.
The team in C2 was highly cross-functional and possessed a high knowledge within
the project and they also had a good dialogue among the team members. The project
manager in C3 said they did not focus on their team being cross-functional. This fits
with the statement of one of the team members, which meant their team lacked some
business knowledge. Also this team member meant there were too few people
involved in the project. The team in C1 started out having a good collective set of
knowledge. Unfortunately this changed somewhat as the progress moved forward,
and some of the team members had to be replaced due to different reasons
(elaborated in the following section). This resulted in the loss of collective knowledge
that had been gained in the team during the early phases of the project.
As we see in this section, all three project managers would profit on focusing on
more than just business functional knowledge when selecting their team members,

Page 26 of 32
especially in C1 and C2. It is understandable that ERP technical knowledge and
technology management knowledge did not get prioritised, since these types of
skillsets probably are not that common for a general employee. Interpersonal skills
and Team skills on the other hand are skillsets that are easier to obtain and they are
crucial when people are going to work together in a team for an extended period of
time, which usually is the case with an ERP implementation project. The project
managers in C1 and C2 should have at least considered Interpersonal skills and
Team skills when selecting their team members.
5.1.3Team
Section 4.4.3 shows there have been reported overall good and supportive attitudes
throughout the projects lifespan in all three cases. Although, as mentioned in the
previous section, there were a few team members in C1 that had to be phased out of
the project. This was partly because they had a very negative attitude towards the
project, and the project manager wanted to prevent the negativity from spreading
across the rest of the team. Assuring good support from the team members is
important, however to replace team members is a drastic action since it most likely
will reduce the collective knowledge of the team, which was the case in C1. Instead
of replacing team members one can work to motivate the team and counteract any
negative attitudes as soon as they occur. In C3 there is also seen some variations in
support. Some of the team members did not see the value of a new system at first,
nevertheless this changed as the project rolled on. This meant the project manager
did not have to replace any of the team members.
Some of the team members in C1 on the other hand had to be replaced due to their
lacking ability to handle increased responsibilities. This situation regarded only a few
team members. In general the team members in C1 coped very well with increased
responsibilities. In C2 the project manager was very pleased with how well the team
members handled increased responsibilities, which he claims is a result of the team
members getting assigned interesting tasks. Some of the team members in C3 also
had some challenges related to increased responsibilities. Instead of replacing them,
they got assistance from other employees, which helped them to cope with the
responsibilities.
There is a similarity in the cases regarding freeing the team members from other time
consuming responsibilities. In all three cases, some team members were freed from
tasks outside of the project. Nevertheless, team members in all three cases reported
that non-project related tasks sometimes got in the way of their responsibilities in the

Page 27 of 32
project. One of the team members in C2 said their time was best managed in the
beginning of the project and that they experienced a time squeeze later on. As seen
from the findings in all three cases, there have been taken actions to help balance
the time between the project and other work related tasks. The challenge in all three
cases was to maintain these actions throughout the whole project lifespan. It is
important to constantly work to make sure the team members are freed from other
time consuming responsibilities during the whole project lifespan and not only at the
start. As seen in this section, there have been taken actions to balance the workload
in all three cases and in all of them it has been reported too high workloads at certain
points of the project. This can point to that the actions taken by the project managers
at the start of the projects did not work 100% or it could be that the communication
between the project managers and the team members was not all that good. How to
maintain a project team is not the focus of this research project and therefore it will
not be discussed further in this thesis.
As can be seen in the previous chapter, none of the three project managers focused
on the combination of personalities when they built their team. This posted some
challenges in both C1 and C2.
5.2 Key findings
The three case studies in this research project are different in size, business area
and ERP system. Despite these differences there are some similarities between the
three. Notwithstanding the recommendations found in literature and past research,
none of the three project managers used a structured process when selecting team
members for their implementation team. Team skills, interpersonal skills, ERP
technical knowledge and technology management knowledge were not criteria for the
team members in any of the cases. All three projects faced some challenges making
sure the team members were freed from other time consuming responsibilities during
the whole project lifespan. From C1 one can also see that replacing team members
can affect the collective knowledge of a team.
5.3 Recommendations
It is important to stress that the findings from the ERP implementation projects across
the three case studies may be unique for each of the subjected organisations.
Despite this, the findings, combined with the recommendations found in literature and
past research, make the ground for the recommendations in the thesis. The
recommendations are collectively presented in Table 13 at the end of this chapter.
The thesis recommends using adequate time to build a good internal implementation

Page 28 of 32
team before commencing an implementation of an ERP system. When selecting
team members it will be beneficiary to use a structured selection process, which the
project managers in both C1 and C2 also recommended. The criteria in such a
selection process should be based on skillsets such as Business knowledge,
Interpersonal skills and Team skills. This will result in team members that know the
business and its processes well and who also know how to interact with other
employees and work as a team. ERP technical skills and technology management
skills are also recommended in literature and past research. These skillsets are
definitely an advantage, however in literature they are recommended as skills for
graduates who are perusing a career in ERP systems. It can be harder to find such
skillsets among employees that does not have a background in information
systems/technology.
It is important that the team is cross-functional like in C1 and C2. Therefore it is
important to make sure that every business area of an organisation is represented in
the team. Since the team will gain a collective set of knowledge during the project
lifecycle, it is important that this knowledge is kept in the team. This means striving to
maintain the original team composition during the entire project lifecycle, as in C2
and C3. One should try to avoid replacing team members, as it will most likely lead to
the loss of collective knowledge in the team, which was the case in C3.
Team members need to be supportive of the project from the very beginning. This
was not the case in C1 and to some extent in C3, which posted challenges.
Therefore the project managers need to motivate the team members and counteract
any negative attitudes as soon as they occur to prevent the negativity from spreading
across the team.
The combination of different personalities and roles are also important when building
a team, which is why this thesis recommends using methods like the MBTI and the 8
Belbin roles to help optimize such combinations.
When selecting the team members it is also essential to make sure they are freed
from other time consuming responsibilities outside of the project. This means
checking with the department managers who are responsible for the employee’s daily
tasks, if this is possible. One can use temporary employees to lighten the workload,
which was done in C3. These actions have to be maintained during the entire project
lifecycle. It is also necessary that the team members report to the project manager
when the workload is getting too heavy. If these actions are not followed it can result
in a time squeeze and even overworked employees. This was partly the situation in
all three cases.

Page 29 of 32
Category: Recommendation:
Selection
Use adequate time to build a good internal
implementation team.
Use a structured selection process when selecting
team members.
Skills
The criteria in the selection process should be based
on skillsets such as business knowledge, interpersonal
skills and team skills.
Make sure that every business area of an organisation
is represented in the team.
The project manager should always strive to maintain
the original team composition during the entire
project lifecycle to avoid losing valuable knowledge.
Team
Motivate the team and counteract any negative
attitudes as soon as they occur to prevent the
negativity from spreading across the team.
Use methods like the MBTI and the 8 Belbin roles to
optimize the combination of personalities and roles
Make sure that the team members can be freed from
other time consuming responsibilities outside of the
project and make sure that this action is maintained
during the entire project lifecycle.
Table 13 Recommendations

Page 30 of 32
CHAPTER 6 CONCLUSION
6.1 Concluding summary
One of the first things a company needs to do when they are going to implement an
ERP system is to establish an internal implementation team. Many books and
research papers have been written on which skills that are important to possess by
the team members, how they should be selected and critical success factors related
to this. The thesis focuses on combining these recommendations and critical factors
and sum up how to best select team members for an ERP implementation project. A
qualitative approach was taken and three case studies were conducted to investigate
how three Norwegian companies have done such a process. Semi-structured
interviews were used to gather data from project managers and team members in the
three companies. The data was structured into tables making it easier to compare the
recommendations found in literature and past research. Key findings were presented
and examples of such findings are that none of the project managers used a
structured process when selecting team members. Team skills, interpersonal skills,
ERP technical knowledge and technology management knowledge were not criteria
for the team members in any of the cases. At last recommendations were made; the
thesis recommends using adequate time to build a good internal implementation
team. When selecting team members it will be beneficiary to use a structured
selection process. The criteria in such a selection process should be based on
skillsets such as business knowledge, interpersonal skills and team skills. It is
important to make sure every business area of an organisation is represented in the
team to make it cross-functional. The project manager should always strive to
maintain the original team composition during the entire project lifecycle to avoid
losing valuable knowledge. The project manager has to make sure that the team
members are supportive and counteract any negative attitudes as soon as they
occur. Finally, it is important to make sure the team members are freed from other
time consuming responsibilities during their involvement in the implementation
project.
6.2 Research contributions
This master thesis has investigated how three Norwegian companies in different
business areas have selected team members for their internal implementation teams
when implementing an ERP system. The findings have been presented and
compared to recommendations found in literature and past research. Based on this
comparison the thesis has presented recommendations on how to best select

Page 31 of 32
internal team members and maintain the implementation team when implementing an
ERP system. This will lead to a bigger and more quantitative research that can
statistically validate these trends and therefore further benefit academia. It will also be
useful within industry, since it will help companies to realise the impact of selecting
internal human resources and give them recommendations on how to do this.
6.3 Limitations
No research is perfect and this thesis is no exception. The findings presented in the
thesis are not statistically generalisable since it only studies three case studies.
Therefore the findings may not apply in other organisations. Only Norwegian
companies have been investigated and business cultures in other countries may not
suit the recommendations represented in the thesis.
One of the predefined questions asked the team members whether they preferred to
double-check issues with other colleagues outside of the project. This was meant to
indicate whether the interview object had the required business knowledge. Only one
of the six team members across the three cases felt there was no need to double-
check with other colleagues before making a decision. This question turned out to be
ambiguous since the outcome could indicate that this one person had full control and
the other did not, nevertheless it could also indicate that the five other team members
also were in full control but double-checked as a safety measure. Because of the
uncertainty regarding this question it was not given any attention in the analysis.
The number of interview objects became less than desired to get a representative
selection of the team members across the three case studies.
Limitations occur when interviewing people that are not objective. There are always
the possibility that the interview objects are not 100% truthful when answering
questions that reflects their own contribution and abilities.
There are mentioned a few actions that should be maintained throughout a project
lifecycle in this thesis. This has not been the primary focus of the research project
and therefore not mentioned in detail and referenced to literature and past research.
6.4 Future research
As mentioned in the previous section, by conducting this research project, future
research can focus on a bigger and more quantitative research that can statistically
validate the findings presented in this thesis.
Future research can also focus on creating a framework for the structured selection
process that is recommended in the thesis and test it in real life ERP implementation
projects. A future research can also increase the focus to include companies from

Page 32 of 32
several nations instead of just focusing on Norwegian companies. By doing so the
focus will expand beyond the Norwegian organisational culture.
This thesis mentions a few actions that should be maintained throughout a project life
cycle. This can be investigated more in-depth in future research since it has not been
the core focus of this research project.
6.5 Personal Reflections
Some of the strengths and weaknesses in regards to working on this master
dissertation will be presented in this section. Getting companies to contribute to this
research project, as case studies, seemed to be very easy at the beginning of the
project. This led me not to investigate in depth which resources were available for
interviews in each company. As the months passed, one after the other could not
contribute with the required resources. This delayed the data collection part of the
project at least one month and the number of interview objects had to be less than
desired. If I had investigated each case study company more in depth at initial
contact, I would have found suitable companies at a much earlier point in the project
and could have started the data collection much earlier.
Before starting on my master degree I worked on an ERP implementation project,
which gave me great insight into challenges related to such a project. This
experience was really helpful and gave me some perspective during my research
project.

Page 33 of 32
REFERENCES
ANDRÉ, M., BALDOQUÍN, M. G. and ACUÑA, S. T. (2011). Formal model for
assigning human resources to teams in software projects. Information and
Software Technology, 53, 259-275.
BHATTI, T. 2005. Critical Success Factors for the Implementation of Enterprise
Resource Planning, Bhatti 2005. The Second International Conference on
Innovation in Information Technology.
BINGI, P., SHARMA, M. K. and GODLA, J. K. (1999). Critical Issues Affecting an
ERP Implementation. Information Systems Management, 16, 7-14.
CADLE, J. and YEATES, D. (2008). Project Management for Information Systems.
CHEN, I. J. (2001). Planning for ERP systems analysis and future trend. Business
Process Management Journal, 7, 374 - 386.
CHEN, I. J. and SMALL, M. H. (1996). Planning for advanced manufacturing
technology. International Journal of Operations & Production Management,
16, 4-24.
COFFEY, A. and ATKINSON, P. (1996). Making Sens of Qualitative Data, London,
Sage Publications.
DE KORVIN, A., SHIPLEY, M. F. and KLEYLE, R. (2002). Utilizing fuzzy
compatibility of skill sets for team selection in multi-phase projects. Journal of
Engineering and Technology Management, 19, 307-319.
FINNEY, S. and CORBETT, M. (2007). ERP implementation: a compilation and
analysis of critical success factors. Business Process Management Journal, 13,
329 - 347.
FRAME, J. D. (1995). Managing Projects in Organizations, San Fransisco, Jossey-
Bass Inc.
GORLA, N. and LAM, Y. W. (2004). Who should work with whom?: building
effective software project teams. Commun. ACM, 47, 79-82.
GRIX, J. (2004). The Foudation of Research, New York, Palgrave Macmillan.
KOH, S. C. L., SAAD, S. and ARUNACHALAM, S. (2006). Competing in the 21st
century supply chain through supply chain management and enterprise
resource planning integration. International Journal of Physical Distribution
& Logistics Management, 36.
KUMAR, P. P. and M.P.THAPLIYAL, D. (2010). Successful implementation of ERP
in large organization. International Journal of Engineering Science and
Technology, 2, 3218-3224.
MILES, M. B. and HUBERMAN, A. M. (1994). Qualitative data analysis: an
expanded sourcebook, SAGE Publications, Inc.
MOHAMED, S. and MCLAREN, T. S. (2009). Probing the Gaps between ERP
Education and ERP Implementation Success Factors.
MUSCATELLO, J. R. and CHEN, I. J. (2008). Enterprise resource Planning (ErP)
Implementations: theory and Practice. International Journal of Enterprise
Information Systems, 4.
NAH, F. F.-H., LAU, J. L.-S. and KUANG, J. (2001). Critical factors for successful
implementation of enterprise systems. Business Process Management Journal,
7, 285 - 296.
OTERO, L. D. and OTERO, C. E. (2012). A fuzzy expert system architecture for

Page 34 of 32
capability assessments in skill-based environments. Expert Systems with
Applications, 39, 654-662.
PATEL, J. 2010. A Study of Problems Affecting ERP Implementation Processes.
London: Brunel University.
PESLAK, A. R. 2006. The impact of personality on information technology team
projects. Proceedings of the 2006 ACM SIGMIS CPR conference on computer
personnel research: Forty four years of computer personnel research:
achievements, challenges & the future. Claremont, California, USA:
ACM.
STRATMAN, J. K. and ROTH, A. V. (2002). Enterprise Resource Planning (ERP)
Competence Constructs: Two-Stage Multi-Item Scale Development and
Validation*. Decision Sciences, 33, 601-628.
TRIMMER, K. J., PUMPHREY, L. D. K. and WIGGINS, C. (2002). ERP
implementation in rural health care. Journal of Management in Medicine, 16,
113 - 132.
WOO, H. S. (2007). Critical success factors for implementing ERP: the case of a
Chinese electronics manufacturer. Journal of Manufacturing Technology
Management, 18, 431 - 442.
YIN, R. K. (2009). Case Study Research, Sage Publications Inc.

Page 1 of 32

Selecting internal team members when implementing an ERP system 2012

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Selecting internal team members when implementing an ERP system 2012

Similar to Selecting internal team members when implementing an ERP system 2012 (20)

Recently uploaded

Recently uploaded (20)

Selecting internal team members when implementing an ERP system 2012