Determining Project Management Practices for Enterprise Resource Planning System Projects

ERP is a class of IT systems which has been developing rapidly since the beginning of the 1990s; Ray (2011) explains that ‘enterprise’ means any organization with a set of common goals. Hossein (2004) specifies that the system integrates and automates processes within the entire organization regardless of what kind of organization it is: a private company or a public or state organization. Successful implementation, support, maintenance and further development of ERP is vitally Abstract

important for the existence of any organization. Elimination of problems related to the ERP system is essential for the secured functioning and development of the enterprise. The authors assume ERP projects have the same nature as any other software projects, acquiring the same signs of failure, success, risk and challenges. Ineffective project management techniques could be recognised as the intrinsic risk factors while accurate project management (PM) practice determination is definitely one of the key influencers of success. But the dilemma is how to improve the PM approach.
A wide range of literature sources recommend using Waterfall-based PM methodologies, which imply cascading, step-by-step realisation, a long planning period and delivering results at the end of the project. But the Waterfall-based approach should not be considered as the only valid methodology in a rapidly changing business environment as enterprises need to adopt and exploit flexible and dynamic methods and procedures of business process reengineering, bringing agility to ERP projects to ensure necessary changes in an acceptable timeframe.

Theoretical Basis of the Research
Hossein (2004) defines ERP as "an integrated computer-based system, which manages internal and external organizational resources". Ray (2011) offers a definition which is pretty much the same: "ERP is an integrated informational system built on a centralized database and having a common computing platform that helps in effective usage of an enterprise's resources and facilitates the flow of information between all business functions of the enterprise and external stakeholders". Both Ray (2011) and Hossein (2004) maintain that ERP-class software is not only about planning and that this term doesn't reflect the actual meaning and capabilities of the ERP system -the software helps run business functions throughout the whole organization. Eckartz et al. (2009) recognizes three groups of ERP benefits: operational benefits, which include improved business processes, cost reduction, productivity and quality customer service improvement, and revenue increase; managerial benefits, which include improved decision-making and organizational performance; and strategic benefits, which include support of business growth, building business innovations, and cost leadership. Bradford (2015) added some other important advantages for organizations adopting ERP: data integration, real-time access to information, and standardization of business processes throughout the enterprise, including branches and subsidiaries. According to the Panorama consulting solutions report (2017), 17% of organizations would like to improve business performance by implementing ERP for better customer service (8%), preparing a company for growth (9%) and ensuring proper and timely reporting (14%).
Researchers mention the following project types: • Initial implementation of an ERP system at an enterprise; • Rollout, which is needed at large multinational companies for common business process support at branches and subsidiaries (Aloini et  Large companies that have been using ERP for many years could still ask for constant enhancements, which are required due to fast-paced business development. ERPrelated activities such as "data migration activity" and "consolidation and harmonization" might be considered as a separate project, but more often these tasks belong to the implementation project type. The concept "harmonization" could be data realized as "data harmonization" (Bradford, 2015) or harmonization of the ERP system with organizational business processes (Hurbean and Fotache, 2010) as well as harmonization of various software applications and data sources. If so, it can't be combined with consolidation projects as they have a different aim and include the opposite activities. Munkelt and Volker (2013) acknowledge that implementation projects include different types of customization of ERP systems. They categorize sub-types of implementation project types, maintaining that there are codeless configurations, application development configurations and customized report configurations. If an organization has some specific business processes and there are some gaps in ERP software, it might be necessary to develop specific applications.
The authors completely agree with Hossein (2004), who pointed out the challenges of every ERP project: product complexity, which could require special consultancy; considerable time consumption; and high implementation costs. The next common problem mentioned in many sources (Tarhini et al., 2015, Ray, 2011, Kimberling, 2012 which essentially impacts an ERP project is change resistance in the customer's organization. But there may also be other important aspects of ERP introduction: quality of business process design, establishing key performance indicators, measurement of performance, employee training, etc. Insufficient evaluation of these factors could lead the project to failure. According to Ray (2011), there have been several cases where implementation projects were not successful, but this seems to be an understatement. From many other sources, it is clear that ERP implementation is a real test for an organization. The International Project Management Association (2016) acknowledged such project failure criteria as going over the budget or deadline and lack of required quality delivered. Finishing the project within the budget is one of the main factors of success (Murray, 2009). For the success of every project, it is necessary to show the project's positive effect at the earliest stage, so the authors assume that splitting the project into smaller parts, which could be delivered to stakeholders as soon as they are implemented, might have a positive influence on the success of the whole project. Most ERP projects employ the old-school Waterfall-based project management approach that is recommended by a wide range of literature sources and vendors' methodologies (Ray, 2011, Capgemini, 2012, Harmon, 2016. This means that the company has to freeze its business processes for 17-25 months while the ERP project is executed, which is not possible in real life and could negatively impact business results, even dramatically deteriorate market shares and the satisfaction of customers. Responding to market demands, companies need to change their business processes regularly, and ERP projects have to be aligned to this strategy. The traditional Waterfall approach, with its long planning and realization cycles, can't be used as the only approach in such a sensitive area as business process automation. Companies should also employ new methodologies, which bring agility to ERP projects and support a flexible and dynamic attitude in strategy realization (Capgemini, 2012).
We completely accept the statement that in case an organization is changing the scope of business requirements during the lifecycle of the project, this could be the cause of ERP implementation project failure (Ray, 2011). Robson (2013) emphasizes that requirements identified at the gathering stage should be revised at the realization stage and the reason is usually the time difference between requirement elicitation, modelling and delivering. Users are unable to define their requirements precisely due to their lack of understanding of ERP system capability. Using a cascading, step-by-step ERP project execution framework inevitably leads to time and cost overrun, customer dissatisfaction, and lack of planned benefits. It is well outlined that organizations should have an effective PM approach to control all stages of realization (Al-Fawaz et al., 2008). Previous studies emphasize the role of PM among the critical success factors required for successful ERP implementation (Ramburn et al., 2013), stressing that poor PM is a main reason for ERP implementation failures.
Despite various previous studies in the ERP field, a clear procedure for PM practice determination related to ERP introduction at an enterprise has not yet been formulated. Many related questions appear when a company is facing the challenge of introducing new ERP or is trying to enhance the existing one: how to determine PM practice? What might be the consequences?
How should they be treated? Which PM practice should be chosen considering the project's characteristics and conditions?

Research Design
In Figure 1, the conceptual model of the research is given.  This is an exploratory study; the empirical data were gathered in March-April 2017 during two series of interviews with experts in the project management and ERP system fields. Sixteen experts participated in the research; the respondents were considered as experts according to the following criteria: • significant work experience in the field related to the research; • a leading position and role at their companies; • certification in the field of PM; • experience in participating in international projects at leading international IT companies.

______________ Tatjana Vasiljeva and Elena Berezkina
The research design is shown in

Figure 2: Research Design (
Two phases of research were conducted. the first phase, the experts in management field were interviewed. objective was to identify the contemporary PM practices appli projects and evaluate the influencing PM practice determination for IT projects. In the second phase experts in the ERP project interviewed. The objective was to ERP project types and factors influencing PM practice determination for application in ERP projects. All interviews were conducted directly by the authors to-face meetings or Skype meeting structured interviews with similar set basic questions for every set respondents were accomplished, with some specific questions which were raised during every interview depend experts' answers. The answers were documented in a specially designed template.

Research Results and Discussion
In

Research Design (created by the authors)
were conducted. In the experts in the project field were interviewed. The identify the main practices applied in IT the factors influencing PM practice determination for the second phase, the field were was to identify d factors influencing PM practice determination for application All interviews were by the authors in faceor Skype meetings. Semistructured interviews with similar sets of basic questions for every set of were accomplished, with some specific questions which were raised during every interview depending on he answers were specially designed Traditional PM practice is called Waterfall because of its cascade-like structure. In Waterfall methodologies, the project development process goes through several sequential phases from the beginning till the end, and the customer can evaluate the work results at the very end of every phase, when it is already late to adopt changes. (Mills, 2016) Traditional plan-driven development according to Cobb (2016) is totally planned in advance, so there is a low level of uncertainty. Business users approve the well-defined requirements before the actual start of the project, the team meets the requirements within the schedule and budget, and any project scope changes are not welcome, making the project inflexible and very constant. Munkelt and Volker (2013) and Chow et al.

Results and
(2016) maintain that project models for ERP system introduction resemble the traditional Waterfall approach to software development.
The main idea of the Agile ideology is the priority of high customer satisfaction, frequent software delivery for competitive advantage, and high motivation of the customer's representatives and developers who provide sustainable development of working software (Beck et al., 2001). Within Agile, practitioners outline the main Agile methodologies, also mentioned in fundamental literature: Scrum, Lean, Kanban, Extreme Programming XP, Crystal, DSDM, and FDD. All of them follow the same philosophy and practices, but "from an implementation standpoint, each methodology has its own recipe of practices, terminology, and tactics" (McLaughlin, 2016). Most PM methodologies, frameworks and approaches described in the literature were also cited by the experts. They were encouraged to mention any number of relevant PM practices, and some experts were keen to give as wide a picture as possible. A list consisting of 17 methodologies, frameworks and approaches was obtained. The practitioners also mentioned that in some cases they employed their own, in-housedeveloped methodologies. The most frequently used contemporary PM practices in software development projects in the international IT landscape according to the experts are given in Figure 3.

RQ2: What factors influence PM practice determination for different types of ERP projects?
The project environment and various internal and external organizational factors have an impact on how projects are conducted. Major factors influencing the outcome of a project include the project's characteristics, environmental factors of the company and external factors (Murray, 2009). PMBOK Guide, PRINCE2, and IPMA PEB have underlined environmental factors that may influence the project's performance and success.
All factors are categorized according to the following groups.

Project factor group:
• Stakeholders' level of engagement; • Stakeholders' risk tolerances; • Geographic distribution of facilities and resources, etc.

External factor group:
• Government or industry standards; • Authorities' regulations; • Quality standards.
Conducting the practical research, the authors found out which particular factors truly influence PM practice determination in an ERP project. The list of factors was offered to PM experts for discussion, evaluation and supplementation with other factors which are important for determining a methodology. The experts have extended the list with several factors related to the project, the customer's company and the external environment. The experts were asked to evaluate the factors on a scale of 1 to 10, where 1 = no influence on PM practice determination and 10 = significant influence. 0 means that this factor wasn't mentioned by the respondent at all. For the purpose of further research, it was decided to use only those factors which were evaluated with a score of 6 or more by at least three experts or evaluated with any score by the majority of experts. This theoretical statement was fully confirmed by the interviews' results, allowing the authors to compile a list of 20 factors influencing PM methodology determination in projects. These 20 factors were taken to the next step of the research for evaluation. The prioritized list of influential factors is given in Table 1. For the clarity of the research, the expert's name and particular evaluation of every factor was excluded and only the average score of the factor was shown in Table 1.
All factors in the list were arranged by average evaluation score. The factor "Level of project uncertainty" was evaluated with a score of 9 or 10 by the majority of the experts; the average score is 8.63. This means that most of the PM experts participating in the research recognized this factor as significant. The factor "Product quality standards" was evaluated with scores ranging from 1 to 9, and its average score is 4.75. This means that the importance of this factor for PM practice determination is not significant according to the experts.

RQ3: What ERP project types are performed on the ERP systems market?
The following types of ERP projects are mentioned in the literature: initial implementation, rollout, upgrading (software version updates), maintenance and support, and consolidation and harmonisation. This list is based on Ray Due to inconsistencies and contradictions in ERP projects type definitions, the authors found a research gap which this study aims to fill. Based on the expert interviews, the classification of ERP projects types was updated, each type having different characteristics, work scope and duration.
Implementation -Initial implementation of an ERP system at a company which did not have one before. SAP experts use the term 'greenfield'; Oracle experts qualify this type of project as a 'fresh' implementation. Both characteristics mean that there wasn't any serious level of business process automatization beforehand and an initial configuration of business processes in ERP is required. Customization of an ERP system may become part of initial implementation if the company's business processes differ significantly from standard ERP system business processes. Maintenance and support -When an ERP implementation project is finished, the next stage is system monitoring, fixing bugs, change requests and realizing small ERP module enhancements. From the PM point of view, this type of project is the most flexible, enabling diversity in PM practices.

Rollout
Upgrading (software version updates)all experts included this type of ERP project in the list as ERP vendors constantly improve their software to increase productivity for better business outcomes, encouraging customers to move their business processes from obsolete software to new versions.

Consolidation,
integration via harmonization - Ray (2011) proposed consolidation and harmonization integration as a type of ERP project, but the experts explicitly distinguished these two types of integration. They insisted that integration via consolidation of different applications on a single ERP platform is in fact a type of rollout project. As for integration-via-harmonization projects, most of the experts acknowledged that this constitutes an independent project type. Its purpose is the integration of systems built on different ERP platforms or on different versions of the same ERP software. The aim is the harmonization and constant exchange of data originating from different sources.
Ray (2011) mentioned migration projects as one of the projects types; however, not all experts who participated in the research acknowledged this view. If a company transfers its business processes from one ERP system to another due to its natural growth or the need to move from a legacy ERP system, the consultant has to create all the settings in a new system. From the new ERP system team's point of view, this is initial or "greenfield" implementation. Data migration from an external source to the target system may be part of any project type above. Based on the findings of the first phase of the research, ERP experts were asked which PM practices are applied in different types of ERP projects. Their answers demonstrated the very high level of conservativism in the ERP market and the extremely slow pace of new trends and experience adoption. Of the great variety of PM practices, the experts mentioned just five, though every expert was permitted to give multiple answers -see   As the next step, the authors compiled a list of factors influencing PM practice determination in IT projects. ERP systems experts identified the most appropriate methodology for each of the ERP project types. As a result, it was possible to find out the impact of every factor and every factor's values on PM practice determination and to construct a matrix for assessing project parameters (conditions) and project environments for PM practice determination.
Some factors were evaluated as not applicable for particular projects types and were excluded from the summary tables. This means these factors have no influence on PM practice selection. For example, the factor 'Stakeholders' geographical distribution' doesn't have any effect on PM practice determination in implementation projects. A list of nonapplicable factors for projects is given below: • Stakeholders' geographical distribution; • Stakeholders' cultural differences; • Market competition in the projectrelated area; • Alignment of a project's objectives with company strategy; • Product quality standards; • Quality of the project's definition of objectives; • Stakeholders' risk tolerance; The final step of the research was constructing a matrix for assessing project conditions and environments and for determining which PM practices are most suitable for a particular project. An example of a factor evaluation matrix for the implementation project type is given in Table 2 below. The highest score is '3', for the Waterfallbased methodology that is recommended by the majority of experts for the chosen project type with appropriate conditions.

Conclusions
The significance of the given research lies in the investigation of arranging and managing ERP-related projects in the most appropriate way and increasing the effectiveness of relevant information technology use for competitive advantage. The comparison of empirical information with the theoretical background as well as the overall results the research obtained could assist an enterprise in choosing relevant PM practices for a particular project, achieving better business indicators and delivering an effective IT environment for business users and stakeholders.

Further Research
The authors intend to continue research on the "Matrix for PM practice determination for ERP projects", test the matrix in different types of real projects, analyse the results and adjust the main parameters of the matrix to improve the PM practice determination process.