Project Management of ERP Implementations: A Case Study

Category: Management

 

1.     Introduction and Context

The case company is a well-established Swiss consultancy specialised in enterprise resource planning (ERP) implementations.

Most ERP implementation projects are complex and therefore costly and such projects have a high failure rate (Hitt, Wu and Zhou, 2002; Sumner, 2000; Parr and Shanks, 2000; Davenport, 1998). Proper project management measures have to be in place to maximise the success rate (Nah, Zuckweiler and Lau, 2003; Umble and Umble, 2002; Sumner, 2000).

This paper investigates how projects are managed by the case company and identifies potential for improvement.

2.     Literature Review

2.1.   Some Project Management Issues of ERP Implementation Projects

Project manager: It is crucial to involve project managers in all the phases of the project (Bancroft et al., 1998). In the author’s experience it can be a challenge to achieve such constant involvement if project management is delivered by a consultancy. Clients are sometimes tempted to minimize the time spent by the external project management to minimise direct project cost.

Project duration: Sauer and Cuthbertson found in their survey of UK Information Technology (IT) projects that the ideal project duration is between three and six months (Sauer and Cuthbertson, 2003). Most ERP implementation projects exceed this recommended duration, due to the complexity (see below) of such projects. PMP Research UK did a survey on the project duration of such ERP projects, asking enterprises what duration they had experienced or were expecting: “70% of our sample believed that anything from 6 months to two years was about right” (PMP Research, 2001, p.1).

Task complexity: By listing the tasks of ERP implementation projects it can be seen that such projects are as much business modelling projects as they are IT projects. This makes them more difficult to handle; Grover et al. (1995) found in their research business modelling problems (e.g. the lack of an appropriate business process re-engineering methodology) as much as IT specific problems (e.g. a limited information systems application infrastructure).

A list of the major tasks in ERP projects confirms the business modelling / IT duality.

  • Re-engineer the clients current business processes (Parr and Shanks, 2000; Sumner 2000).
  • Design the new way to do business based on the ERP software modules used (Sumner, 2000; Parr and Shanks, 2000).
  • Define the gap between the processes supported by the software and the targeted new business model (Soho et al., 2003; Francalanci, 2001; Parr and Shanks, 2000).
  • Build functionality into the ERP software that was identified in the gap analysis as missing or requiring adaptation (Francalanci, 2001; Parr and Shanks, 2000).
  • Ensure that the client’s technical infrastructure is capable of running the ERP software in a way that handles its workload (Sumner, 2000; Escalle and Cotteleer, 1999).
  • Implement process changes necessary to implement the targeted new business model within the client’s organi­sation, converting existing data to the ERP system as necessary (Adam and O'Doherty, 2000).

End user training: Working in accordance with the new processes requires that the respective systems run and that people are capable of operating the systems properly. Otherwise the live implementation will be severely challenged or even fail. Robey, Ross and Boudreau (2002) report of a case where “practicing on sample data did not prepare employees for live implementation ‘It’s like turning out the lights; people didn’t know where they were going’ (p.28). Obviously adequate training is most important to achieve this and such training has to simulate live situations, including the handling of exceptions.

Task model: A lot of task models for ERP implementation projects can be found in literature. Some of them do not end with the going live of the ERP system. For example Kraemmeraard, Møller and Boer (2003) explain that “further performance tuning and changes” and “continuous business improvement” is necessary (p.343). From a project management point of view, a project needs a well defined end; later activities have to be separately (PMI, 1996). Many task models base on a sequential information system life cycle, referred to as cascade models (Zanoni and Audy, 2004, p.30) or waterfall models (Ahituv, Neumann and Zviran, 2002, p.56). Other models base on a concept of iterative development, called prototyping models (Ahituv, Neumann and Zviran, 2002, p.56) or incremental models (Zanoni and Audy, 2004, p.30). All these models incorporate checkpoints, usually called milestones. In the last years extreme programming - a highly iterative model without milestones - was developed, forming a third type of model. It is only used in software development (Wallin, Ekdahl and Larsson, 2002).

Which of the models is best for our case company is elaborated in 3.6. Improvement Potential in Software Implementation Planning.

2.2.   Core Areas of Enterprise Resource Planning Projects

During an ERP implementation, different skills are needed from a consultancy as the case organisation. These skills can be assigned to four core competence areas:

  1. Business process modelling (BPM): the client implementing an ERP system has to synchronize the business processes currently in use with those bundled into the package (Gattiker and Goodhue, 2002; Curran and Keller, 1998).
  2. Design of software modifications: it is not always possible to use a business process embedded in the ERP package; consequently the package will have to be adapted to Support new or modified processes. Such modifications should be carefully planned and documented using appropriate modelling methods (Nah, Zuckweiler and Lau, 2003; Murray and Coffin, 2001; Scheer and Habermann, 2000). “The ultimate goal should be to improve the business – not to implement software” (Umble, Haft and Umble, 2003, p.245).
  3. Implementation of software modifications: changes documented in the design step have to be implemented using programming techniques compatible with the ERP package and have to be carefully tested (Nah, Zuckweiler and Lau, 2003; Rosario, 2000).
  4. Technical infrastructure implementation: The systems necessary to run the ERP software have to be designed and implemented. For high transaction volumes, this can be a challenging task (Grossman and Walsh, 2004). In the author’s experience the database servers involved have to be optimized by experts. Appropriate tuning can make the difference between unacceptable performance and a smoothly running system. Kraemmeraard, Møller and Boer (2003) report a case where running material resource planning (which has to run while no user is on the system) took an unacceptable 8-10 hours. Optimisation reduced this to acceptable 2 ½ hours (maximum time-window for such a job at night is usually 3-4 hours). The Design of the system can have long reaching consequences as “due to its pervasive nature, a new ERP platform forms a critical infrastructure in any company for at least the next decade” (Holland and Light, 1999, p.34).

 As will be shown later, the case company’s organisation is matching these skill areas.

2.3.   Business Process Modelling

“Enterprise Resource Planning (ERP) systems have the potential to integrate seamlessly organizational processes using common shared information and data flows”
(Huang et al., 2004, p.101).  

Such ERP systems integrate business processes from different functional areas and eventually even different companies e.g. suppliers and customers (Al-Mashari, 2003). This leads to improved enterprise performance. “We find that ERP adopters are consistently higher in performance across a wide variety of measures than nonadopters” (Hitt, Wu and Zhou, 2002, p.93). Due to the direct cost involved and the indirect cost of the changes to established processes, a reduced performance can be observed in the first two years after the implementation; leading to an improved return on asset about four years after the implementation (Nicolaou, 2004).

To realise such performance gains, companies will have to adapt their business processes to inherent limitations of the ERP package used (Gattiker and Goodhue, 2002; Teltumbde, 2000; Davenport, 1998).

Gattiker and Goodhue (2002, p.4801) classify the four possible implementation types for business processes using ERP software as:

  • Not changing current business processes:
    • existing process are successfully modelled in ERP, no change necessary;
    • ERP system is changed to fit existing processes; change is done to the system instead of the process.
  •  Changing current business processes:
    •  Current process is changed to ERP-imbedded process, as ERP system cannot implement the current process;
    • current process is changed to ERP-imbedded process, as ERP systems’ process is seen as superior to current process.

One could be tempted to believe that the bigger the change and the impact on the processes the higher the potential gain (or loss in the case of a failure) for the company implementing the ERP system. But Gattiker and Goodhue (2002) found that a company’s business strategy alignment is the key point. Process changes made that increase process ó strategy alignment result in positive ERP impact, whereas process changes that decrease process ó strategy alignment create negative ERP impact.

 2.4.   Design & Implementation of Software Modifications

Two programming paradigms exist. Procedural programming and object-oriented programming (Patrizio, 1997). X++, the programming language of the ERP systems implemented by the case organisation, is following the object-oriented paradigm.

Literature also distinguishes between two project management paradigms, according to the two software development paradigms (Zanoni and Audy, 2003). The first is called procedural project management (PPM) which is based on PMI’s project management body of knowledge (PMI, 1996). PPM usually implements some iterative steps in the project’s task model in the form of a spiral model (PMI, 1996, pp.15-16). The second is object-oriented project management (OOPM), which usually bases on the unified process (UP), originally developed by Rational Software as rational unified process (RUP) (Zanoni and Audy (2003). These authors state that the UP usually implements more and shorter iteration cycles than PPM and that it is based on the methodological toolkit unified modelling language (UML). “UP is guided by use cases, centred in the architecture, interactive and incremental” (Zanoni and Audy, 2003, p.30).

For a project that will be implemented using the object oriented paradigm it is possible to use either of the two project management methods. To aid the selection process Zanoni and Audy (2003) listed the characteristics of the two approaches (p.30). The following table shows this list, which has been adapted by Feldmann (2005) to best cover the needs of Axapta implementation Projects:

Characteristic

PPM

OOPM

Project division into phases

ü

ü

Spiral model

ü

ü

UML management

û

ü

Object / abstraction usage in project management

û

ü

Embedment and package usage

û

ü

Project control process

ü

û

Project planning process

ü

û

Project accomplishment process

ü

ü

Project closing process

ü

û

Project management view

ü

û

Table 1 -  Comparing procedural (PPM) and object-oriented (OOPM) project Management: Characteristic is supported (ü) or not supported (û) by the respective method.

It can be seen from Table 1 that PPM does not cover the unified modelling language, objects, abstractions or packages. OOPM on the other hand has its weakness in the support of project management processes.

2.5.   Technical Infrastructure Implementation

ERP systems benefit from “a full, integrated environment that uses a common IT infrastructure and is built on an open systems’ architecture” (Al-Mashari, 2003, p.46). Such a server and communication infrastructure has to be designed and build along the implementation of the ERP package to ensure this system is up and running for testing and later to go live in production; the client side of such systems has to be deployed to ensure users can access the central core systems. Brown (2004) put this as “combined corporate and frontline involvement with IT is needed continually”.

Sumner (2000) states that a technical infrastructure which underperforms and turns into a “technological bottleneck” (p.324) can be an important risk factor. Several sources give examples of ERP failures as a result of such bottlenecks.

Such a bottleneck of the rather extreme sort is reported by Escalle and Cotteleer (1999): A system that processed 420’000 orders per night was replaced by an ERP system. It was then found that this new system was only able to process 10’000 orders per night, which did not allow the company to appropriately process its workload – leading, as you might expect, to severe problems.

3.     Case Study

3.1.   The Case Company and Key Issues of Its Business

 The case organisation is specialized in implementing Axapta (Microsoft’s ERP solution for larger companies) and has subsidiaries in Austria, Germany and Switzerland. It has a total of about 120 employees. About half of them work in Switzerland; where the head office is located. The employees work in a positive setup and are highly motivated. This leads to a very low employee defection rate (below 1% in 2004, only one junior person resigned) and consequently to a high level of experience.

Key issues of the case company, relevant to project management.

  • The average project manager is very experienced and very successful (see below).
  • To win a contract often requires commitment of a fixed price and a fixed completion date. At this early stage in the project it is impossible to base time and price commitments on a detailed analysis, increasing project risks.
  • There are only a few binding standards established for project management. As a consequence every project manager has his or her personal way to manage projects.
  • Axapta, the ERP system the case company implements, consists of many different and complex modules. Due to this complexity, many different specialists are necessary to do the projects. Most of the specialists cover only a specific part of the modules and for most of the modules there are only one or two specialists available.

 The case company is organized in four teams:

  • Project Team: responsible for project management, business process modelling, design of software modifications and pre-sales activities.
  • Programming Team: responsible for implementation of software modifications including testing of modifications.
  • Technical Team: responsible for the technical infrastructure implementation including client installations, server sizing, implementation and tuning.
  • Sales & Administration: responsible for tasks like sales, running the reception, accounting etc.

This organisation reflects the core areas of ERP projects (see p.5).

3.2.   Common Structure of Case Company’s Projects

Almost all projects follow the same scheme. The following figure shows when the teams have phases of high involvement:

Figure 1- Structure of Projects

3.3.   Current Project Management

Interviews with current project managers show that “excellent project management techniques are used” as has been demanded by Umble and Umble (2002, p.32) and the elements of project management required by these authors are in place and well established (definition of objectives, development and work plans including a resource plan and milestones etc).

 Business process modellers from the project team write detailed specifications, as postulated by Grossman and Walsh (2004). If software changes are necessary, these specifications also contain a description of the software changes. The specifications are handed over to the programming team to make and test these changes. A final test of the software is conducted by the project team as the completed changes are handed back to them.

3.4.      Improvement Potential of Software Specifications

A quick survey of challenges in current projects and their sources has shown that almost a third of the problems have to do with the specifications that are handed over to software implementation. The specifications are reported to be either incomplete or ambiguous.

There is no standard established for these specifications, every project manger does so in his or her own way. It seems as if the interaction between the project and the programming departments lacks a common language, a fixed formalism based on a well established methodology.

In choosing a technique to specify the software changes, a whole zoo of methodologies is available from which techniques can be borrowed? Two different approaches are possible: selecting a technique from the domain of business process modelling, as the specification is the output of the business process modelling step, or selecting from the domain of IT methodologies as the goal is software specification.

Sauer and Cuthbertson (2003) claim IT projects to be very distinctive and that “project management practices from other sectors therefore do not apply” (p.57). This is a strong argument for choosing a technique from an IT methodology. Sumner (2000) states that “commitment to using project management methodology and ‘best practices’ specified by vendor” (p.326) for software systems design is positively reducing project risk. Microsoft, the vendor of Axapta, not only defines a project management methodology but also gives away (for free) a toolset to support it, which includes a graphical tool to model Use Cases, a software specification technique borrowed from the Unified Modelling Language (UML). UML is a Methodology developed by Rational Software for software specification and documentation of projects that create software that is implemented based on the object oriented paradigm.

An additional important argument for Use Cases is the fact that the technique can be used in isolation, without also implementing UML’s other techniques. Therefore Use Cases is the technique of choice proposed to remove the weakness in software specification.

3.5.   Implementation of Software Changes

All implementations by the case organisation include some programming to adapt existing modules. Detailed specifications of the desired behaviour of the system are handed over from the project team to the programming team to implement and test these functionalities. This implementation and the testing have to be planned, executed and documented. There is no formal way to plan these activities. The responsibility for project management, including the definition of tasks and milestones, is with the project team, using project management techniques that are not tailored towards object oriented programming.

3.6.   Improvement Potential in Software Implementation Planning

A classical sequential task model for the ERP project is used, such models have been introduced above (p.4) as waterfall models. Due to the complexity of the implementation tasks and to facilitate the involvement of end users the programming team often uses an iterative approach which in literature is often referred to as a prototyping model.

The fact that planning is done using a sequential approach but actual implementation uses prototyping and leads to a mismatch in the planning parameters used, with the consequence of time management problems and suboptimal task prioritisation.

It would be beneficial if the project team would only set the project management frame for the programming team to plan more detailed using IT specific techniques that support the object oriented programming paradigm best. For such specifications the unified process methodology has been introduced in 2.4. Design & Implementation of Software Modifications (p.7).

The literature review has shown that the unified process is weak on the process side but well supporting the object oriented implementation. As a lot of the project management is done by the project team, especially on the process side. Consequently the unified process is a good choice and only a subset of the Unified Process is necessary. Such a tailored model is proposed here to be used by the programming team to optimally support its requirements. The exact definition of the subset to be used is not within the scope of this paper (see 4.2. Next Steps and Proposal for Further Studies).

4.     Conclusion

Average success rates in the UK are 9% failed, 75% challenged and 16% successful IT projects (Sauer and Cuthbertson, 2003). ERP implementation projects seem to do worse, Martin (1998) reports over 90% challenged or failed, leading to a success rate below 10%. Compared to these IT project success rates, the case company does very well. No project failed in the years covered by the survey, leading to a failure rate somewhere in the range of 0% to 5%; only every second project is challenged (time or budget), leading to a success rate somewhere around 50%.

4.1.   Recommended Improvements

Even though project management seems to do fine in the case company, potential for improvement has been identified. Two major issues were found and respective solutions proposed:

 i)      A communication issue: the interaction between the project and the programming teams lacks a common language, leading to inefficiencies. It has been shown that the Use Case technique can be applied to close this gap.

 ii)     An implementation planning issue: project management is done by the project team with techniques that are not tailored towards object oriented programming, leading to time management problems and suboptimal task prioritisation in the software development. A subset of the Unified Process has been proposed to improve time management and task prioritisation for the programming team. This best supports the object oriented programming paradigm in use.

4.2.   Next Steps and Proposal for Further Studies

High project management standards are well established in the case-company. There is no urgent need for immediate action and a step by step approach should be used to improve on the two issues mentioned above.

First use case modelling should be introduced, as two teams will profit and as work on the issue can be started without an additional study.

Only after use case modelling is firmly established in several projects, a first project can be initiated which uses a simplified version of the unified process. Before this can happen, an additional study is necessary that defines how the unified process methodology needs to be tailored for the specific case.

After the successful completion of a first project, all new projects should incorporate software development planning based on the specified methodology.

Appendix A – References

Adam, F. and O'Doherty, P. (2000) Lessons From Enterprise Resource Planning Implementations in Ireland – Towards Smaller and Shorter ERP Projects.
Journal of Information Technology, volume 15 issue 4, pp.305-316.

Ahituv, N.; Neumann, S. and Zviran, M. (2002) A System of Development Methodology for ERP Systems. Journal of Computer Information Systems, volume 42 issue 3, pp.56-67.

Al-Mashari, M. (2003) A Process Change-Oriented Model for ERP Application.
International Journal of Human-Computer Interaction
, volume 16 issue 1, pp.39-55.

Bancroft, N.; Seip H. and Sprengel A. (1998) Implementing SAP R/3. 2nd ed,
Greenwich: Manning Publications.

Brown, W.  (2004) Enterprise Resource Planning (ERP) Implementation Planning and Structure: A Recipe for ERP Success. ACM, SICUSS’04, 10.-13. October 2004, Baltimore.

Curran, T. and Keller, G. (1998) SAP R/3 Business Blueprint: Understanding the Business Process Reference Model. Englewood Cliffs: Prentice Hall.

Davenport, T. (1998) Putting the Enterprise Into the Enterprise System.
Harvard Business Review, volume 76 issue 4, pp.121-131.

Escalle, C. and Cotteleer, M. (1999) Enterprise Resource Planning, Technology Note.
Harvard Business School Case #699-020, Boston: Harvard Business School Publishing.

Feldmann, S. (2005) Is Critical-Chain Project Management Beneficial to ERP Implementa­tions: A Case Study. Unpublished Assignment, Glasgow: University of Strathclyde.

Francalanci, C. (2001) Predicting the Implementation Effort of ERP Projects: Empirical Evidence on SAP/R3. Journal of Information Technology, volume 16 issue 1, pp.33-48.

Gattiker, T. and Goodhue D. (2002) Software-Driven Changes to Business Processes: An Empirical Study of Impacts of Enterprise Resource Planning (ERP) Systems at the Local Level. International Journal on Production Research, volume 40 issue 18, pp.4799-4814.

Grossman, T. and Walsh, J. (2004) Avoiding the Pitfalls of ERP System Implementation. Information Systems Management, volume 21 issue 2, pp.38-42.

Grover, V. ; Jeong, S.; Kettinger, W. and Teng, J. (1995) The implementation of business process reengineering. Journal of Management Information Systems,
volume 12 issue 1, pp.109-144.

Hammer, M. and Champy, J. (1995) Reengineering the Corporation: A Manifesto for Business Revolution. London: Nicholas Brealey Publishing.

Hitt, L.; Wu, D. and Zhou, X. (2002) Investment in Enterprise Resource Planning: Business Impact and Productivity Measures. Journal of Management Information Systems,
volume 19 issue 1, pp.71-98.

Holland C. and Light, B. (1999) A Critical Success Factors Model for ERP Implementation. IEEE Software, volume 16 issue 3, pp.30-36.

Kraemmeraard, P.; Møller, C. and Boer, H. (2003) ERP Implementation: An Integrated Process of Radical Change and Continuous Learning. Production Planning & Control, volume 14 issue 4, pp.338-348.

Martin, M. (1998) An Electronics Firm Will Save Big Money by Replacing Six People With One and Lose All This Paperwork, Using Enterprise Resource Planning Software, But Not Every Company Has Been So Lucky. Fortune, volume 137 issue 2, pp.149-151.

Murray, M. and Coffin, G. (2001) A Case Study Analysis of Factors for Success in ERP System Implementations. Proceedings of the Seventh Americas Conference on Information Systems, Boston, pp.1012–1018.

Nah F., Zuckweiler K. and Lau J. (2003) ERP Implementation: Chief Information Officer’s Perceptions of Critical Success Factors. International Journal of Human-Computer Interaction, volume 16 issue 1, pp.5-22.

Nicolaou A. (2004) Firm Performance Effects in Relation to the Implementation and Use of Enterprise Resource Planning Systems. Journal of Information Systems,
volume 18 issue 2, pp.79-105.

Parr, A. and Shanks, G. (2000) A Model of ERP Project Implementation.
Journal of Information Technology, volume 15 issue 4, pp.289-303.

Patrizio, A. (1997) Object Theory is Fine, Practice is Better. InformationWeek,
issue 624, pp.12-13.

PMP Research (2001) PMP 2001 Survey – ERP Continues to Have a Major Impact on Manufacturing Systems. PMP Research Paper, Amersham: PMP UK Ltd.

PMI (1996) A Guide to the Project Management Body of Knowledge. 1996 ed,
Newtown Square: The Project Management Institute.

Robey D., Ross J. and Boudreau M. (2002) Learning to Implement Enterprise Systems: An Exploratory Study of the Dialectics of Change. Journal of Management Information Systems, volume 19 issue 1, pp.17-46.

Rosario, J. (2000) On the Leading Edge: Critical Success Factors in ERP Implementation Projects. BusinessWorld (Philippines), May 17, 2000.

Rummler, G. and Brache, A. (1995) Improving Performance: How to Manage the White Space on the Organization Chart. 2nd ed, San Francisco: Jossey-Bass.

Sauer C. and Cuthbertson C. (2003) The State of IT Project Management in the UK 2002‑2003. Available online, http://www.computerweeklyms.com/pmsurveyresults/index.asp
accessed May 7th 2005.

Scheer, A. and Habermann F. (2000) Enterprise Resource Planning: Making ERP a Success. Communications of the ACM, volume 43 issue 4, pp.57-61.

Smith, H and Fingar P. (2003) Business Process Management (BPM): The Third Wave.
Tampa: Meghan-Kiffer Press.

Soh, C. et al. (2003) Misalignments in ERP Implementation: A Dialectic Perspective. International Journal of Human-Computer Interaction, volume 16 issue 1, pp.81-100.

Sumner, M. (2000) Risk factors in enterprise-wide/ERP projects.
Journal of Information Technology, volume 15 issue 4, pp.317-327.

Teltumbde, A. (2000) A Framework for Evaluating ERP Projects.
International Journal of Production Research, volume 38 issue 17, pp.4507-4520.

Umble E. and Umble M. (2002) Avoiding ERP Implementation Failure.
Industrial Management, volume 44 issue 1, pp.25-33.

Umble E., Haft R. and Umble M. (2002) Enterprise Resource Planning: Implementation Procedures and Critical Success Factors. European Journal of Operations Research,
volume 146 issue 2, pp.241-257.

Wallin C., Eckdahl, F. and Larsson, S. (2002) Integrating Business and Software Development Models. IEEE Software, volume 19 issue 6, pp.28-33.

Zanoni, R. and Audy, J. (2004) Project Management Model: Proposal for Performance in a Physically Distributed Software Development Environment.
Engineering Management Journal,
volume 16 issue 2, pp.28-34.