Project Management Institute

High stakes


Project consultants must tap the right stakeholders at the optimal time during enterprise resource planning implementations.


Virtually everything that project managers worry about can go wrong in enterprise resource planning (ERP) implementations. At Glendale, Calif., USA-based Nestlé USA Inc., executives experienced those troubles firsthand, leading them to halt a $210 million ERP project less than halfWay through. “No major software implementation is really about the software,” says Jeri Dunn, former Nestlé chief information officer.

In essence, an ERP package collects and presents real-time data to enable decision-making using the most current enter-prisewide information available. From 1998 to 1999, an average full-scale ERP system implementation took 23 months, according to the Meta Group, Stamford, Conn., USA. These “companies-in-a-box” have business processes built into them, and the complex implementations often require specialist expertise. While the technical aspects of the implementation are important, consultants must communicate often with stakeholders to ensure the process flows smoothly.

Unlike smaller software packages that affect one part of the company or another, ERP systems impact every part of the enterprise. Because all stakeholders should be involved, consultants must prioritize whom to talk with and when to include stakeholder input. Representative users from each affected area must have enough time away from their normal jobs to provide constructive input.


The legislature gave us 16 months to get the Arkansas Administrative Statewide Information System up and running. But the implementation schedule and the training schedule both were compressed.


When setting up the project plan, all stakeholders must understand the full scope of the project, including the size of the hardware and software to be purchased and installed, the modules to be implemented, how much customization will be necessary and when work will be complete.

The information technology (IT) department gathers the detailed technical data on the mechanics of the installation that consultants need. The greatest amount of programming time in the project likely will be spent customizing the interfaces between the new ERP system and the existing IT systems and extracting, transforming and loading (ETL) the information from the legacy databases. Consultants should identify several IT representatives early and train them in the ERP system to lead the process.

The U.S. State of Arkansas learned the importance of customization and ETL when it converted to an SAP system, officially going live on 1 July 2001. However, agency guidelines for processing interface transactions were not available until 2 July 2001. State agencies scrambled to create the necessary transactions for recording cash receipts, budget transfers, warrant (check) requests and purchase requisitions. In addition, several days after the official go-live date, agencies were told that they had to do their own data conversion, indicating that the system was “officially” turned on prior to any data was entered. Agencies had to enter their own accounts receivable open items as of 30 June 2001 and ensure the balances were correct.

At planning, the IT department should identify the total number of users and concurrent users; these numbers impact the hardware, storage and data throughput needed. In addition, project managers must consult with department managers to communicate how their departments will be affected by the new ERP system and to gain buy-in for these extensive changes.

In some packages, upper-level managers and executives should indicate if they want predetermined or created-as-needed information. Upper management needs to oversee the project's progress and step in if absolutely necessary. For example, when Credit Suisse Financial Services Group (CSFS), the second largest financial services company in Switzerland, had trouble with a PeopleSoft implementation in 1999, CSFS Finance Chief Phil Ryan made a personal appeal to PeopleSoft's Chairman Dave Duffield. His letter sparked a visit by Duffield and People-Soft's new Chief Executive Officer Craig Conway to Credit Suisse's headquarters— and a renewed commitment by PeopleSoft to ensure the implementation would be successful.


During the actual customization process, the users have less involvement in most ERP systems; they verify that what was requested during the design phase is indeed what they wanted. At this point, consultants should be prepared for everything from small tweaks to the screens to major redesigns.

In some ERP systems, the design and customization phases can be concurrent. A user sits down with the programmer while he or she is modifying the set of screens the user will need. After the user has approved the screens, the programmer can build the connections to the actual data and create the queries that will provide the information requested.

At Silgan Inc., a manufacturing company, the implementation team traveled to Silgan's plants in Indiana and Illinois, USA, meeting with the employees to build the screens they would use in their day-to-day work. While the corporate offices promised full company cooperation with the implementation team, the plant managers in the field refused to give their employees enough time away from their normal jobs to work with the team. The project ran well over budget because the company paid the consultants to wait for employees.

Requirements and Design

During the requirements phase, project managers will enlist upper-level managers and the executives who are the end users of the data. Consultants must learn user expectations and the impacts of these requirements.

For instance, CSFS decided to implement PeopleSoft based on requirements set by its four business units. “Financial information can now be captured via standardized transactional accounting applications and then aggregated, based on specific business unit requirements,” says Urs Oberholzer, ERP and CSFS IT program director. Because transactions would number more than 2 million per day, there was debate about which hardware to use. Although Credit Suisse had two data centers with one manufacturer's mainframes, it elected to go with a different system that produces more than 2,000 business unit reports at month's end.

“The initiative for change came from the business units, and as they took a major role in all stages of the implementation, the project was able to deliver what was required,” says then CSFS Program and Business Director Stefan Hilber, who implemented the system.

Even if an ERP system requires little or no customization, consultants must still meet with the users. In 1998, DuPont Chemical and Merck & Co. executives spun off a joint effort named Endo Pharmaceuticals to manufacture two prescription drugs, Percodan and Percoset, as a joint subsidiary. Endo project managers implemented an SAP system using SAP‘s Accelerated Solutions program. The technical implementation was completed in four months, but the executives spent the prior three months in question-and-answer sessions with SAP consultants. These meetings enabled Eric Bloom, vice president of IT at Endo Pharmaceuticals, to see that customization would not meet his company's needs. Instead, SAP added industry-specific modules that can share data to improve business operations and provide features to help track pharmaceutical sales to different types of customers, such as retailers and wholesalers.

Installing a simple system is much easier in a new company, such as Endo, with no established procedures. For older companies, analysts must spend considerable time identifying the existing business processes impacted by the new system.

Each process requires an impact assessment and some determination of the size of the change. If time and budget allow, a return-on-investment (ROI) calculation should be done on a process-basis to help executives decide whether they want to keep the existing process and heavily modify the package or to use an unmodified package and change the process.

These changes are identified at a high level during the requirements-gathering phase of the project and carried on in detail during the implementation phase. A large-scale process, such as a manufacturing procedure, encompasses a number of lower-level practices. Because outside consultants are not familiar with the internal details of a company's processes, the points of contact are integral to improvements.

Because process redesign often is cyclic, going back and making changes is a fact of life. During design, the project team also may reengineer some established processes. For example, users and designers may sit down at generic screens and plan the screen layout and some parts of the processes together. These types of process changes must involve people with intimate knowledge of the existing methods.

From a time management standpoint, the process changes must have a clear end date so the programmers still have time to complete their design, customize the package and test the system before the project deadline.

User representatives must be involved for functionality and usability testing. During stress testing, a few users should log on and use the system to assess whether the system runs quickly enough for day-to-day use, even under heavy-load conditions.

Last-minute training can be costly. The State of Arkansas held many of its training sessions after it officially had gone live. On its second payday, the system failed to produce paychecks for 130 employees and underpaid 293 others. “The legislature gave us 16 months to get the Arkansas Administrative Statewide Information System up and running,” says Dick Barclay, director of Arkansas’ Finance and Administration Department. “But the implementation schedule and the training schedule both were compressed.” Most of the problems with the system resulted from operator error, Barclay says.

By involving stakeholders throughout the project process from planning to training, consultants can rest assured that an ERP implementation will run smoothly. PM

From a time management standpoint, the process changes must have a clear end date so the programmers still have time to complete their design, customize the package and test the system before the project deadline.


Frank Parth is director of the project technology office at Pacific Life Insurance Co., Newport Beach, Calif., USA.

Joy E. Gurnz is vice president of development at

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI.




Related Content