- Open Access
Causes and remedies for the dominant risk factors in Enterprise System implementation projects: the consultants’ perspective
© Lech. 2016
- Received: 9 September 2015
- Accepted: 16 February 2016
- Published: 29 February 2016
The purpose of this research was to investigate the causes of the dominant risk factors, affecting Enterprise System implementation projects and propose remedies for those risk factors from the perspective of implementation consultants. The study used a qualitative research strategy, based on e-mail interviews, semi-structured personal interviews with consultants and participant observation during implementation projects. The main contribution of this paper is that it offers viable indications of how to mitigate the dominant risk factors. These indications were grouped into the following categories: stable project scope, smooth communication supported by the project management, dedicated, competent and decision-making client team, competent and engaged consultant project manager, schedule and budget consistent with the project scope, use of methodology and procedures, enforced and enabled by the project managers, competent and dedicated consultants. A detailed description is provided for each category.
- Enterprise System
- ERP implementation
- Project risk
- Project failure
- Project management
Enterprise Systems (ES) are the backbone of the IT infrastructure of most global manufacturing and service enterprises (Muscatello and Chen 2008). Formerly identified with Enterprise Resource Planning (ERP) applications (Davenport 1998; Sedera and Gable 2010), these commercial off-the-shelf (COTS) systems have evolved from plain ERP toward more sophisticated application suites that include ERP, Customer Relationship Management, Business Intelligence, Workflow, Content Management, and other functionalities, which are required to support the information flow and workflow in organisations. Adapting the Klaus et al. (2000) definition, an ES is a standard, customisable application suite that includes integrated business solutions for the major business processes and administrative functions of an enterprise, with the ERP system being the central component of this suite. Enterprise Systems have become a fundamental tool in many industries, i.e., a ‘must-have’ to maintain competitive position on both global and local markets (Al-Mashari et al. 2003; Helo et al. 2008; Beheshti and Beheshti 2010), and these systems continue to attract the attention of researchers (Al-Jabri and Roztocki 2015; Bernroider et al. 2014: Eden et al. 2014; Koch and Mitlöhner 2010; Ram et al. 2014; Trąbka and Soja 2013).
There is a great deal of discussion concerning the criteria that should be used to designate an implementation a failure (Basten et al. 2011; Basten and Pankratz 2015; Lech 2013a; Yeo 2002), leading to considerable research on implementation success and failure factors regarding both Information Systems in general, and Enterprise Systems in particular. However, there is no doubt that many ES projects still face problems with meeting their original scope, budget, and/or schedule (Belassi and Tukel 1996; Dezdar and Sulaiman 2009; Kappelman et al. 2006; Mu et al. 2015; Nah and Delgado 2006; Nelson 2007; Ram et al. 2014; Somers and Nelson 2001; Schmidt et al. 2001; Soja and Paliwoda-Pękosz 2009; Yeo 2002).
Critical success factors
Dezdar and Sulaiman (2009)
Somers and Nelson (2001)
95 articles published between 1999 and 2008 in top IS journals
65 research articles and 110 case studies from popular literature, published between 1983 and 2000
Top management support and commitment
Top management support
Use of a steering committee
Top management support
A project champion
Project management and evaluation
Business plan and vision
Clear goals and objectives
Change management programme
Management of expectations
Change management procedures
Use of a consultant
Use of consultants
Use of consultants
Careful selection of ERP software
Careful package selection
Choice of architecture
Selection of the proper system
Business process reengineering and minimum customisation
Business Process Reengineering
BPR/Limited customisation of the system
Partnership with vendor
Use of vendors’ tools
Team dedication/involvement in the project
ERP team composition, competence and compensation
Project team competence
Expertise of the team
User training and education
User training on software
Enterprise-wide communication and cooperation
Effective communication and cooperation
Education on new business processes
Software analysis, testing and troubleshooting
Data analysis and conversion
Use of methodology
As can be seen from the table above, both literature reviews present lists of success factors that can be easily matched to each other. The matching was done in the table with the use of the ‘common category’, which is self-explanatory in almost all cases. Additional explanation may be needed for the last category, i.e., ‘Use of methodology’. The two success factors grouped under this category are ‘software analysis, testing and troubleshooting’ and ‘data analysis and conversion’. These categories constitute important elements of the implementation methodology but it also has other elements, so a more general category was used as a common denominator.
The critical success factors in Table 1 are high level and are presented from the perspective of the adopting organisation. While they are extremely valuable for the steering committee members, project sponsors, and project managers, a more in-depth, practical list would be useful for the successful execution of the project. For example, a more detailed list would specify exactly what is meant by proper project management, effective communication, or the selection of a proper system. Only a few studies on CSFs have presented an in-depth analysis of sub-factors (e.g., Nah et al. 2003; Ngai et al. 2008; Somers and Nelson 2001).
Project risks/failure factors
Kappelman et al. (2006)
Early warning signs
Critical failure factors
Schmidt et al. (2001)
Poor estimation and/or scheduling
Lack of top management support
Underestimate of timeline
Lack of top management commitment to the project
Ineffective stakeholder management
Weak project manager
Weak definitions of requirements and scope
Misunderstanding the user requirements
Insufficient risk management
No stakeholder involvement and/or participation
Inadequate project risk analysis
Not managing change properly
Weak commitment of project team
Incorrect assumptions regarding risk analysis
Failure to gain user commitment
Short-changed quality assurance
Team members lack requisite knowledge and/or skills
Ambiguous business needs and unclear vision
Lack of adequate user involvement
Weak personnel and/or team issues
Subject matter experts are overscheduled
Lack user involvement and inputs from the onset
Conflict between user departments
Insufficient project sponsorship
Lack of documented requirements and/or success criteria
Top down management style
Changing scope and objectives
Poor determination of requirements
No change control process (change management)
Poor internal communication
Number of organisational units involved
Inattention to politics
Ineffective schedule planning and/or management
Absence of an influential champion and a change agent
Failure to manage end-user expectations
Lack of user involvement
Communication breakdown among stakeholders
Reactive and not pro-active in dealing with problems
Unclear/misunderstood scope and objectives
Resources assigned to a higher priority project
Consultant/vendor underestimated the project scope and complexity
Improper definitions of roles and responsibilities
No business case for the project
Incomplete specifications when project started
Lack of frozen requirements
Inappropriate choice of software
Introduction of new technology
Changes in design specifications late the project
Lack of effective project management skills
Involve high degree of customisation in application
Lack of effective project management methodology
Lack of required team knowledge/skills
Although the level of detail and the exact naming of particular risk factors differ across the literature, it can be assumed that there is agreement between the researchers on which risk factors negatively affect the ES projects.
However the answers to the questions ‘Why do these failure factors emerge in most of the ES projects?’ and ‘What remedies can be applied to compromise the most prominent risk factors?’ are not usually answered. Furthermore, all of the research cited above presents the risk factors from the perspective of an adopting organisation, while a typical project landscape consists of three parties (Haines and Goodhue 2003): the adopting organisation (implementer, client), the system vendor, and the consulting enterprise (consultant) that helps the adopting organisation to implement the system successfully. For a description of the role of consultants in the implementation of an Enterprise System project, see Lech (2013b). Therefore, it is a promising research direction to investigate the failure factors in more detail and to present a perspective other than that of the adopting organisation. This study investigated the causes of the dominant risk factors and proposed remedies for those risk factors from the perspective of the implementation consultants involved in ES projects.
Ranking of the most influential risk factors according to consultants
1. Unclear/changing goals/scope/requirements
2. Communication problems
3. Lack of client team dedication to/involvement in the project
4. Poor project management
5. Lack of change management procedures
6. Poor planning/estimation/scheduling
7. Improper/insufficient client team expertise
8. Consultants overscheduled
9. Lack of/insufficient resources/consultants
10. Lack of decision-making capabilities in the client team
The above list was a starting point for the study presented in this paper. The aim of the study was to investigate the causes of those dominant risk factors and propose remedies for them from the perspective of implementation consultants involved in ES projects. The results of the research are presented in the following sections. The methodology of the research is presented in the “Methods” section at the end of the paper.
Stable project scope
‘Unclear/changing goals/scope/requirements’ was indicated as the most important risk factor. The reasons, according to the consultants, are the lack of client team dedication to the project in its early phases when the project scope included in the contract is being detailed and transformed into the system design, improper change management and a lack of system knowledge in the client team. The consultants did not indicate errors in the project scoping/bidding phase, most probably because they are responsible for project execution, not for planning and preparation, and they treat the project scope, schedule, and budget as imposed. The planning of an ES project, especially regarding budget and schedule, is an understudied research area. A recent literature review on ES, made by Eden et al. (2014), does not include any papers covering that topic. More research is available on ERP Requirements Engineering. A summary of this research is presented in Daneva and Wieringa (2010).
The consultants also indicated other factors that determine the stability of the scope of the project during execution. One of the initial phases of a project (after project planning) is the design (or blueprint) phase. During this phase, abstract requirements that are included in the project scope are transformed into detailed specifications, describing how these requirements will be included in the new system. Careful execution of this step significantly increases the probability that the system will meet the client company’s needs. Therefore, active participation of the client project team, including the participation of its business domain experts, is crucial in this phase, as these are the people who can detail the requirements and verify that the solutions proposed by the consultants are in line with these requirements. Achieving this goal is much easier if the client project team is familiar with the system being implemented. As this is rarely the case, the client project team should go through preliminary training, during which the basics of the system are presented. Whenever possible, the design process should be supplemented by demonstrations of the functionality of the system. This will help the members of the client project team to visualise the solutions included in the system design (Blueprint) document. According to the consultants who participated in the interviews, this is only possible in specific situations, such as when the functionality to be presented does not require substantial system configuration.
Another factor that helps to keep the scope of the project stable is change management. According to the consultants interviewed, this means resistance to uncontrolled changes of scope by the consultant project manager, as well as eagerness to adapt the business processes to the system functionality of the client organisation, and management of the expectations of the client’s management. As consultants are only one part of the project team, these findings should all be compared with the findings of the studies that considered the point-of-view of the client. Consultants are motivated to accomplish the project within a given scope, budget and schedule. However, if the scope of the project is not determined with enough care, or the business environment of the client organisation has changed during the course of the project, it may be necessary to change the scope and adjust the schedule and budget accordingly (Lech 2013a). On the other hand, the consultants also reported that in some projects, the scope increases drastically due to the incorporation of requirements that are not necessarily related to the company’s core business, but that reflect either current business practices of particular users or that are only included to make the users’ lives easier. Such ‘nice-to-have’ requirements should be carefully evaluated by the client management, who should compare their value added with the resulting increase in budget and time, as well as with the potential increase in future costs related to the maintenance of a highly customised system (e.g., problems during upgrades).
A careful definition of the scope during project preparation/bidding;
Involvement of the client project team in the early phases of the project;
Careful change management and expectations management by avoiding unnecessary system customisation, by adjusting the business processes to the system functionality in non-critical areas, and by resistance to unnecessary changes from the project management.
These recommendations address the risk factors: ‘Unclear/changing goals/scope/requirements’ and ‘Poor planning/estimation/scheduling’.
Smooth communication supported by the project management
‘Communication problems’ ranked second in the list of risk factors, according to consultants. This indicates that, first, communication among the project participants is extremely important and second, that consultants have noticed significant flaws in communication during projects in which they have participated. During the in-depth interviews, the consultants identified causes for communication problems, and suggested remedies for them. The first problem, highlighted by the consultants, is communication ambiguity on the client side. Consultants reported that in some projects, they faced problems with finding the right person with whom to communicate. The lack of a clear communication path results in difficulties with the clarification of questions and with obtaining decisions regarding the required functionality of the system. In the best-case scenario, after addressing a question to all the client team members, they obtained the answer from one of them (which caused unproductivity on the client side, because people who were not responsible for or not able to respond to the question were forced to deal with it). In the worst-case scenario (and the most common one), the question remained unanswered, as no one on the client side felt responsible to react. The remedy to this problem is a single-point-of-contact for each of the consultants, which should be a key-user who is responsible for a given functional area. A communication map, indicating contact persons for each functional area should be clearly defined in the project procedures, and the project managers should be required to enforce it.
Another instance of ambiguity in communication on the client side occurs when different stakeholders pose conflicting requirements. This situation is related to a lack of clear vision regarding the aims and goals of the project, and to politics within the client organisation, especially between different departments. According to the consultants, the remedy for this problem is the presence of a strong project leader on the client side. He/she may also be the project manager or may cooperate closely with the project management team. His/her responsibility is to work out compromises when conflicting requirements occur, or, if this is not possible, to make binding decisions on which of the conflicting requirements is going to be implemented in the system. If the conflict cannot be resolved by the project management team and the project leader, it is the role of the Steering Committee to make a final decision. The consultants emphasised the role of the Steering Committee in solving the major problems in the project.
For this to happen, the conflict between the requirements has to be identified first, which, according to the respondents, should be done during status/integration meetings. All of the respondents pointed towards the importance of status/integration meetings as the main tool for facilitating the communication within and between the functional teams. According to them, status meetings within a team should take place every week, while integration meetings, with the presence of all functional teams, should take place no less frequently than every 2 weeks. These meetings should be structured and facilitated by the project management team. All the decisions made during the meetings should be documented and approved by the team leaders, and appropriate procedures to deal with the identified problems and risks should be applied.
Communication issues between the client and consultant arise due to the aforementioned problems on the client side, but may also be caused by a culture gap, the consultants’ lack of soft skills, or improper task management by the consultants. The culture gap is a phenomena extensively described in the literature and refers to a situation when the two (or more) parties (here, the consultant and the client) cannot communicate properly due to different cultural and professional backgrounds. The classical understanding of a culture gap has assumed that IT people cannot communicate properly with business people due to the lack of knowledge of each other’s domain of expertise. To avoid this situation, the consultants should be the domain experts in their respective functional areas. As this was the case for the interviewees in this research, this classical culture gap was not reported as a failure/risk factor. However, the consultants reported communication problems due to the clients’ lack of system knowledge. This is one of the risk factors that is most difficult to mitigate, as it is hard, if not impossible, to expect the clients to be experts in systems that are new to them. The purpose of involving the consultants in a project is to benefit from their system knowledge, which can then be transferred gradually to the client. During the design phase, however, the client does not usually possess enough knowledge to verify the proposals made by the consultants in an informed way. A partial remedy to this problem is initial training for the client team. However, as ES systems are highly configurable and usually also require customisation, this initial training cannot reflect the configuration/customisation of the target system. Training can be carried out on demo/training systems, but these may differ significantly from the system after it has been configured and customised during the project. Therefore, the aim of this training can only be to familiarise the client with the nomenclature and general logic of the system. Another way of decreasing the culture gap on the client side is to perform demonstrations of parts of the system whenever possible, during the design and early implementation phases. However, this is only possible for those parts of the system that do not require substantial configuration and customisation.
The consultants also indicated that some of the reasons for the communication problems lay solely on their side. These are a lack of soft skills of some of the consultants and improper task management. The lack of soft skills may cause a breakdown in communication between the consultant and his/her counterparts on the client side. The most obvious solution, which is often not easy to achieve, is training the consultants in soft skills. This requires time and has to be done before the project. If communication problems arise during the project, they should be monitored and resolved by the consultant project manager. In the most extreme situations, according to the respondents, the project manager should attend the meetings of a team that is facing communication problems, in order to actively animate the discussions and to help find solutions for problems that have arisen. ‘Improper task management’ involves imprecise statements regarding what is required from the client, a lack of assignment of a responsible person on the client side, and a lack of deadlines. These problems should be resolved by project methodology, part of which is the documentation of every meeting with the client. The documentation format should enforce the preparation of a task list, including the person/people responsible and the deadline for each task. The project manager should control the documentation on a regular basis and enforce the proper documentation of the findings and the tasks.
Communication problems can also occur within the consulting team, between different functional consultants, and between the consultants and their project managers. In fact, these were the communication problems that were most commonly mentioned by the respondents. The causes for communication problems within the consulting team include the lack of consultants’ soft/communication skills, the consultants’ encapsulation within their functional area, and the lack of or improper execution of communication procedures.
These three causes tend to interfere with each other, because the project activities are usually performed on a daily basis within the teams that cover one functional area (e.g., financials, inbound logistics and inventory, outbound logistics and sales, production planning, and execution) and both the consultants and their counterparts in the client team tend to focus on the problems that arise within their respective functional areas. If the consultants lack soft/communication skills, they may tend to avoid confronting the other teams, so it is difficult for them to identify integration points and resolve possible inconsistencies. Also, less experienced consultants may not be aware of the ways that the configuration of their respective functional area may interfere with the configuration in other areas. If, in addition, the communication procedures do not force them to discuss and reconcile these integration issues, the resulting system may be inconsistent, i.e., the fulfilment of the requirements in one functional area may preclude the fulfilment of the requirements in another area.
The remedies for these problems are the inclusion of training of the consultants in soft skills in their career paths, and the careful preparation and execution of the communication procedures during the project. Once again, the key item in communication procedures is the careful preparation and execution of the status/integration meetings. The respondents emphasised the need for the project managers to play an active role in these meetings. They should not only gather information from the teams, but should also actively seek to identify possible integration problems as well as to participate in their solutions. For this to happen, the project managers need to have both company knowledge (the client project manager) and system knowledge (the consultant project manager). The results of these meetings should be documented, approved by the participants, and treated as binding after having been approved.
Consultants must possess knowledge in their functional areas, in order to speak the same language as the clients and understand their requirements;
Consultants should possess strong communication skills;
A clear communication map and communication procedures must be developed and consequently applied;
The client team should learn about the system through initial training and through presentations of the functionality of the system in the early phases of the project;
A strong project leader should be present on the client side to resolve problems with conflicting requirements;
Communication should be monitored and animated by the project managers on a regular basis;
All findings should be documented and approved both by the client and the consultant;
All tasks should be documented and have a person responsible and deadline assigned;
And, most importantly—status/integration meetings must be held frequently, with project managers playing an active role in the identification and solution of the issues that arise.
These recommendations address the risk factors: ‘Communication problems and Lack of change management procedures’.
Dedicated, competent client team with decision-making capabilities
The client team should consist of the domain experts in the areas involved in the implementation. The most competent people should be dedicated to the project as key-users.
The key-users should dedicate at least 50 % of their time to the project in the design and testing phases. Involvement in the realisation phase may be lower, but the more that the key-users are involved in the realisation phase, the less knowledge transfer is needed before and just after the ‘project go-live’.
The key-users should have decision-making capability, i.e., they either should be entitled to make business decisions regarding business process change, and design decisions regarding system functionality if alternatives exist, or else, they should have a short path to the decision makers to enable fast decision making.
Another issue that the client company may face is the difficulty of achieving points 1 and 2 at the same time. The most competent domain experts are usually the most overloaded people in the company, which makes it extremely difficult to take them away from their daily activities so that they can devote half of their time to the project. Consultants identified three approaches for the client companies to solve the issue of overscheduling. The first is to have the domain experts, being the key-users, work overtime for the duration of the project, which requires extremely high motivation. Another approach is to nominate people with less experience but more time as key-users and to grant them access to the domain experts when needed. This resolves overload of the experts but poses additional communication issues between the non-expert key-users and the domain experts. The third solution identified is to hire part-time, additional staff to perform the daily activities, so that the domain experts can concentrate on the project.
These recommendations address the risk factors: ‘Lack of client team dedication’, ‘Improper/insufficient team expertise’, and/or ‘Lack of decision-making capabilities’.
Competent and engaged consultant project manager
Possess the system knowledge and experience from other projects to be able to identify possible risks and problems, and find solutions;
Actively prioritise and coordinate tasks in and between the projects—he/she should be aware of the complexity and interdependencies of the tasks;
Carefully listen to the team, give support and be open to suggestions from the team;
Support the consultants in front of the client—play ‘bad cop’ so that the consultants can maintain a good relationship with the client team;
Actively participate in the identification of problems/risks and their solutions;
Be assertive in front of the client to defend the project scope, budget, and schedule;
Organise and actively participate in the status/integration meetings;
Enable and streamline the communication in and between the teams;
Implement and actively enforce the usage of a project methodology and procedures.
As one of the respondents recapitulated, “There are bad project managers who just administer their MS Project or Excel files, prepare a task list, and expect the tasks to be done somehow, without their involvement. And there are good project managers who just make a project happen”.
These recommendations address the risk factors: ‘Poor project management’ and ‘Lack of change management procedures’.
Schedule and budget consistent with the project scope
Poor planning/estimation/scheduling, together with ‘Lack of change management procedures’ were the two risk factors that refer to the inconsistencies between the scope, and the other two ‘iron triangle’ project parameters, i.e., budget and schedule.
Because consultants have an operational role in the project, being responsible for its execution, and not for its planning and preparation, they tend to treat the project scope, schedule, and budget as imposed. Therefore, in the interviews, they did not give any specific recommendations on how the bidding and project preparation phases should be executed in order to determine a feasible scope, together with a corresponding budget and schedule. However, they did point out some of the causes of inconsistency between the scope, schedule, and budget. The first is unrealistic expectations of the client due to a lack of knowledge about the complexity of the project. The second is acceptance of these unrealistic expectations by the consulting enterprise because of strong competition in the market, reasoning that ‘if we do not take this project, someone else will’ and ‘after we start the project, we will be able to renegotiate the contract once the customer realises that the initial assumptions were not feasible’. The remedy for this is a careful bidding process, including a definition of the scope of the project in a structured and methodological way, and also the inclusion of a realistic budget and schedule, according to that scope. The client should also learn about the specifics of the proposed system and the related complexity of the project before starting the implementation. However, this study did not reveal any particular indications on how this should be achieved. During the execution of the project, it is crucial to apply a proper, methodological procedure for change management. The project manager should resist any change of scope that is not followed by respective adjustments to the budget and the schedule.
These recommendations address the risk factors: ‘Poor planning/estimation/scheduling’ and ‘Lack of change management procedures’.
Use of methodology and procedures, enforced and enabled by the project managers
A timely execution of status/integration meetings;
The careful documentation of all findings;
A precise definition of tasks, with the people responsible and the deadlines assigned to each of them;
A methodological approach to change and risk management;
The careful preparation and execution of the test phase:
Careful preparation of the test scripts;
Proper scheduling of the tests, with enough time granted for corrections between the test runs;
Clear responsibility divided between the project participants.
Once again, it is important to emphasise the role of a project manager in enforcing the application of the methodology during the project.
The use of methodology helps to minimise the following risk factors: ‘Unclear/changing goals/scope/requirements’, ‘Lack of change management procedures’, ‘Poor project management’.
Competent and dedicated consultants
The consultants also complained about some issues regarding their work in the projects, which resulted in the inclusion of the risk factors into the ranking: ‘Consultants overscheduled’ and ‘Lack of/insufficient resources/consultants’.
They stated that they are sometimes assigned to tasks that exceed their competence. Often they are also overloaded, working on several projects at the same time and also supporting the sales processes for new customers. It also happens that the project staffing does not always correspond to the workload. The only remedy that the respondents saw for this overload is a full-time contract, in which a customer pays for 100 % of the consultant’s time. This prevents the consulting enterprise from assigning him/her to another project at the same time. However, this approach may raise the cost of the implementation significantly. Regarding the issue of insufficient competence, the remedy for the customer is to carefully examine the CV’s of the consultants who are supposed to execute a project, interview the consultants, and check their references. It is also a good practice to ensure in the contract that the consultant presented during the project preparation will be actually executing the project.
A summary of the recommendations for improvement of the execution of projects from the consultant’s perspective
Risk factor addressed
Keep the project scope stable
Perform careful project scoping during the bidding process
Assure client team involvement, especially during the design phase
Train the client team in the system before or at the beginning of the project
Prototype during the design phase when possible (so that no substantial configuration and no customisation are needed)
Adjust the business processes to the system functionality in areas that do not harm competitiveness
Manage client expectations: include ‘must-haves’, exclude ‘nice-to-haves’
Introduce and maintain smooth communication supported by the project management
Establish and hold periodic status/integration meetings, empowered and animated by the project managers
Prepare a clear communication map with single points of contact
Introduce and enforce the usage of communication procedures
Document all findings and tasks, and assign responsibility and deadlines to the tasks
Manage conflicting requirements by appointing a strong project leader (champion) on the client side and involve the Steering Committee in problem solving if necessary
Reduce the culture gap by
appointing consultants which have domain expertise and strong soft skills
training the client team in the system
involving prototyping and functionality presentations in the design phase whenever possible
Make the enablement of communication one of the main tasks for the project managers
Lack of change management procedures
Assure dedicated, competent, client team with decision-making capabilities
Assign domain experts to the team as key-users or grant the key-users constant access to the domain experts
Grant the key-users decision-making capability or grant them constant and quick access to the decision makers
Grant the key-users time to participate in the project
motivate them to work over-time; or
nominate less experienced staff as key-users but grant them constant access to experts; or
hire temporary employees to perform the daily activities of the key users
Lack of client team dedication to/involvement in the project
Improper/insufficient client team expertise
Lack of decision-making capabilities in the client team
Appoint a competent and engaged consultant project manager
The consultant project manager should
possess the system knowledge and experience from other projects to be able to identify possible risks and problems, and find solutions
actively prioritise and coordinate tasks in and between the projects—he/she should be aware of the task complexity and interdependencies
carefully listen to the team, give support and be open to suggestions from the team
support the consultants in front of the client—play ‘bad cop’ so that the consultants can maintain a good relationship with the client team
actively participate in the identification and solving of problems/risks
be assertive in front of the client in defending the project scope, budget, and schedule
organise and actively participate in the status/integration meetings
enable and streamline the communication in and between the teams
implement and actively enforce the usage of a project methodology and procedures
Poor project management
Lack of change management procedures
Keep the budget and schedule consistent with the scope
Perform careful project estimation during the bidding process
Avoid wishful thinking—evaluate the impact of changes in scope on budget and schedule rationally
Apply a methodological change management process
Resist any change in scope without schedule and budget adjustments
Lack of change management procedures
Enforce the usage of the methodology and procedures
Execute timely status/integration meetings
Carefully document all findings
Precisely define the tasks, with people responsible and deadlines assigned to them
Apply a methodological approach to change and risk management
Carefully prepare and execution of the test phase
carefully prepare the test scripts
grant enough time for corrections between the test sessions
Define and enforce clear responsibility split between the project participants
Lack of change management procedures
Poor project management
Assure that the consultants are competent and dedicated to the project
As a client
check the consultants CVs and references
assure that the consultants’ expected workload is in line with the project scope
assure that the consultants presented to you will be actually executing the project
Lack of/insufficient resources/consultants
The purpose of this study was to investigate the causes of the dominant risk factors affecting the implementation of Enterprise System projects and propose remedies for those risk factors from the perspective of the implementation consultants.
The research presented in this paper took a different perspective on project risk factors than that of most of the existing literature. Instead of looking at ES projects from the ‘general’ perspective of top management and project management, this study analysed projects from the operational perspective of one of the two parties that actually implement the project—the consultants. The results of this research should be treated as an addition to, not a contradiction of, the existing body of knowledge. The limitation of this study is that it examined only one of the two parties involved in the operational execution of the projects. The results should be compared with research that examines the point-of-view of the client team, which is a promising, and unexplored research area, because most of the research involving users concentrates on the phenomenon of user acceptance. The main contribution of this study is that it offers viable indications on how to overcome the dominant risk factors that negatively affect the everyday work during the implementation of an Enterprise System project. The careful consideration of the causes and the implementation of remedies for the risk factors brought to light by this research should help Enterprise Systems projects to proceed more smoothly and with a greater probability of success.
As discussed earlier in this paper, most of the existing research on the risk factors in ES implementations was performed from the perspective of the adopting organisation, and little is known about the risk factors from the perspective of the consultants. According to Creswell (2009, p. 18), “if a concept or phenomenon needs to be understood because little research has been performed on it, then it merits a qualitative approach”. Therefore, a qualitative research strategy was chosen for this study. The following research questions were posited.
Q1: What are the causes for the risk factors that can occur during the implementation of an Enterprise System project?
Q2: What remedies can be applied to mitigate the risk factors during the implementation of an Enterprise System project?
E-mail interviews were carried out with fourteen ES consultants, during which they were asked to name any number of risk factors that, in their opinion, negatively influence their ability to accomplish the project with success. The interviews were performed as a part of another study on project failure, but as a side effect, the informants also gave substantial insight into the causes of the project risk factors, which motivated the follow-up study, presented in this paper.
Semi-structured face-to-face interviews were carried out with four respondents who were active ES consultants and also had experience as project managers, with seniority ranging from 5 to 15 years, and with accumulated knowledge from 52 full-time implementation projects. The informants were presented with a the list of risk factors depicted in Table 3, and were asked to elaborate on the causes for these risk factors and to suggest remedies that should be implemented to avoid or mitigate them.
Participant observation from six projects in which the author was actively involved as a consultant and/or project manager was included in the data. This data source was used as a triangulation source for interviews with the consultants, for the purpose of double-checking the data saturation in the interviews.
The responses from the e-mail interviews were coded with the use of MAXQDA qualitative research software. The coding procedure was used to answer Q1, i.e., finding the phrases that indicate causes for the risk factors to occur in the project.
During the semi-structured face-to-face interviews, the informants were explicitly asked to define the causes for the risk factors to occur in the project and to propose remedies that may be used to mitigate those risk factors. The interviews were recorded, transcribed, and coded with the use of MAXQDA software. The answers regarding Q1 were triangulated with the results from Step 1. The answers regarding Q2 were open coded and were subject to triangulation during Step 3.
The results of the open coding with regard to risk remedies were triangulated with the use of the field notes from participant observation from six projects.
The results were summarized in a form of a narrative and presented in the above sections of this paper.
The authors declare that they have no competing interests
Open AccessThis article is distributed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made.
- Al-Jabri I, Roztocki N (2015) Adoption of ERP systems: does information transparency matter? Telemat Inform 32(2):300–310View ArticleGoogle Scholar
- Al-Mashari M, Al-Mudimigh A, Zairi M (2003) Enterprise resource planning: a taxonomy of critical factors. Eur J Oper Res 146(2):352–364View ArticleGoogle Scholar
- Aloini D, Dulmin R, Mininno V (2007) Risk management in ERP project introduction: review of the literature. Inf Manag 44(6):547–567View ArticleGoogle Scholar
- Basten D, Pankratz O (2015) Customer satisfaction in IS projects: assessing the role of process and product performance. Commun Assoc Inf Syst 37:430–447Google Scholar
- Basten D, Joosten D, Mellis W (2011) Managers’ perception of information system project success. J Comput Inf Syst 52(2):12Google Scholar
- Beheshti HM, Beheshti CM (2010) Improving productivity and firm performance with enterprise resource planning. Enterp Inf Syst 4(4):445–472View ArticleGoogle Scholar
- Belassi W, Tukel OI (1996) A new framework for determining critical success/failure factors in projects. Int J Project Manag 14(3):141–151View ArticleGoogle Scholar
- Bernroider EWN, Wong CWY, Lai K (2014) From dynamic capabilities to ERP enabled business improvements: the mediating effect of the implementation project. Int J Project Manag 32(2):350–362View ArticleGoogle Scholar
- Creswell J (2009) Research design, qualitative, quantitative and mixed methods approaches. Sage Publications, Thousand OaksGoogle Scholar
- Daneva M, Wieringa R (2010) Requirements engineering for Enterprise Systems: what we know and what we don’t know? In: Nurcan S, Salinesi C, Souveyet C, Ralyté J (eds) Intentional perspectives on information systems engineering. Springer, Berlin, HeidelbergGoogle Scholar
- Davenport T (1998) Putting the enterprise into the enterprise system. Harvard Bus Rev 76:121–131Google Scholar
- Dezdar S, Sulaiman A (2009) Successful enterprise resource planning implementation: taxonomy of critical factors. Ind Manag Data Syst 109(8):1037–1052View ArticleGoogle Scholar
- Eden R, Sedera D, Tan F (2014) Sustaining the momentum: archival analysis of enterprise resource planning systems (2006–2012). Commun Assoc Inf Syst 35:39–82Google Scholar
- Haines MN, Goodhue DL (2003) Implementation partner involvement and knowledge transfer in the context of ERP implementations. Int J Hum Comput Interact 16(1):23–38View ArticleGoogle Scholar
- Helo P, Anussornnitisarn P, Phusavat K (2008) Expectation and reality in ERP implementation: consultant and solution provider perspective. Ind Manag Data Syst 108(8):1045–1059View ArticleGoogle Scholar
- Kappelman L, McKeeman R, Zhang L (2006) Early warning signs of IT project failure: the dominant dozen. Inf Syst Manag 23(4):31–36View ArticleGoogle Scholar
- Klaus H, Rosemann M, Gable G (2000) What is ERP? Inf Syst Front 2(2):141–162View ArticleGoogle Scholar
- Koch S, Mitlöhner J (2010) Effort estimation for enterprise resource planning implementation projects using social choice—a comparative study. Enterp Inf Syst 4(3):265–281View ArticleGoogle Scholar
- Lech P (2013a) Time, budget, and functionality? IT project success criteria revised. Inf Syst Manag 30(3):263–275View ArticleGoogle Scholar
- Lech P (2013b) Enterprise system implementation from the functional consultants’ perspective. Electron J Inf Syst Eval 16(4):291–301Google Scholar
- Mu E, Kirsch LJ, Butler BS (2015) The assimilation of enterprise information system: an interpretation systems perspective. Inf & Manag 52(3):359–370View ArticleGoogle Scholar
- Muscatello JR, Chen IJ (2008) Enterprise resource planning (ERP) implementations. Int J Enterp Inf Syst 4(1):63–83View ArticleGoogle Scholar
- Nah F, Delgado S (2006) Critical success factors for enterprise resource planning implementation and upgrade. J Comput Inf Syst 46(29):99–113Google Scholar
- Nah F, Zuckweiler KM, Lee-Shang Lau J (2003) ERP implementation: chief information officers’ perceptions of critical success factors. Int J Hum Comput Interact 16(1):5–22View ArticleGoogle Scholar
- Nelson RR (2007) IT project management: infamous failures, classic mistakes, and best practices. MIS Q Exec 6(2):67–78Google Scholar
- Ngai EWT, Law CCH, Wat FKT (2008) Examining the critical success factors in the adoption of enterprise resource planning. Comput Ind 59(6):548–564View ArticleGoogle Scholar
- Ram J, Wu M-L, Tagg R (2014) Competitive advantage from ERP projects: examining the role of key implementation drivers. Int J Project Manag 32(4):663–675View ArticleGoogle Scholar
- Schmidt R, Lyytinen K, Keil M (2001) Identifying software project risks: an international Delphi study. J Manag Inf Syst 17(4):5–36Google Scholar
- Sedera D, Gable GG (2010) Knowledge management competence for enterprise system success. J Strateg Inf Syst 19(4):296–306View ArticleGoogle Scholar
- Soja P, Paliwoda-Pękosz G (2009) What are real problems in enterprise system adoption? Ind Manag Data Syst 109(5):610–627View ArticleGoogle Scholar
- Somers T, Nelson K (2001) The impact of critical success factors across the stages of enterprise resource planning implementations. In: Proceedings of the 34th Hawaii international conference on system sciencesGoogle Scholar
- Trąbka J, Soja P (2013) ERP in project-driven organizations: a case study from IT industry in Poland. In:Wrycza S (ed) Information systems: development, learning, security. Lecture notes in business information processing, vol 161. Springer, Berlin, Heidelberg, pp 27–38View ArticleGoogle Scholar
- Wiegers K (1998) Know your enemy: software risk management. Softw Dev 6(10):38–42Google Scholar
- Wu J, Wang Y-M (2007) Measuring ERP success: the key-users’ viewpoint of the ERP to produce a viable IS in the organization. Comput Hum Behav 23(3):1582–1596View ArticleGoogle Scholar
- Yeo KT (2002) Critical failure factors in information system projects. Int J Project Manag 20(3):241–246View ArticleGoogle Scholar
- Yin R (2003) Case study research. Design and methods, Third edn. Sage Publications, Thousand OaksGoogle Scholar