At some point, testing is complete and the project team and project manager then become responsible for ensuring that the information system is transferred successfully
ERP IMPLEMENTATION IN 10 EASY STEPS?
1. Ask the board of directors for an arbitrary but large sum of money ($300 million should suffice).
2. Give half of the money to consultants. Ask them to select an appropriate ERP package for your com pany. Consultants will audit your business processes for six months and then select SAP, which they happen to sell.
3. Form cross-functional implementation teams. Hold meetings.
4. Reengineer all your business processes to match the software model.
5. Give the other half of the money to the consultants.
6. Install the software.
7. Train end users repeatedly.
8. Cross your fingers.
9. Turn on the software.
10. If you're still in business, immediately return to Step 1 because it's time for an upgrade.
SOURCE: From Derek Slater, ERP Implementation in 10 Easy Steps, CIO.COM, April 1, 2001, http://www.cio.com/archive/040101 /tl_erp.html.
from the development and test environment to the operational environment of the sponsor or customer's organization. This transfer requires a tactical approach, and it can be a stressful time for all the stakeholders involved. Choosing an inappropriate implementation approach can negatively impact the project's remaining schedule and budget. In general, the project team can take one of three approaches for implementing the information system. These approaches include (1) direct cutover, (2) parallel, and (3) phased.
Figure 12.1 Direct Cutover
The direct cutover approach, as illustrated in Figure 12.1, is an approach where the old system is shut down and the new system is turned on. In general, a target, or go live, date is agreed upon, and the new system simply replaces the old.
This approach can be effective when quick delivery of the new system is critical or when the existing system is so poor that it must be replaced as soon as possible. Direct cutover may also be appropriate when the system is not mission critical—i.e., the system's failure will not have a major impact on the organization. It is important, however, that the new system be thoroughly tested so everyone is confident that few, if any, major problems will arise.
Although there are some advantages to using the direct cutover approach, there are also a number of risks involved that generally make this the least favored approach except in a few, carefully planned situations. Although the direct cutover approach can be quick, it may not always be painless. You might think of this approach as walking a tightrope without a safety net. You may get from one end of the tightrope to other quickly, but not without a great deal of risk. Subsequently, there may be no going back once the old system is turned off and the new system is turned on. As a result, the organization could experience major delays, frustrated users and customers, lost revenues, and missed deadlines. The pressure of ensuring that everything is right or having to deal with problems and irate users or project stakeholders can create a great deal of stress for the project team.
Figure 12.1 Direct Cutover
As Figure 12.2 illustrates, the parallel approach to implementation allows the old and the new systems to run concurrently for a time. At some point, the organization switches entirely from the old system to the new.
The parallel approach is appropriate when problems or the failure of the system can have a major impact on the organization. For example, an organization may be implementing a new accounts receivable package. Before switching over completely to the new system, the organization may run both systems concurrently in order to compare the outputs of both systems. This approach provides confidence that the new system is functioning and performing properly before relying on it entirely. Although the parallel approach may not be as stressful for the project team as the direct cutover approach, it can create more stress for the users of the system. The users will probably have to enter data into both systems and even be responsible for comparing the outputs. If the new system performs as expected, they may be willing to put up with the extra workload until the scheduled target date when the new system stands alone. If, however, unexpected problems are encountered, the target date for switching from the old to the new system may be pushed back. The extra workload and overtime hours may begin to take their toll and pressure for the project team to "get on with it" may create a stressful environment for everyone involved.
Following the phased approach, the system is introduced in modules or in different parts of the organization incrementally as illustrated in Figure 12.3. For example, an organization may implement an accounting information system package by first implementing the general ledger component, then accounts payable and accounts receivable, and finally payroll.
The phased approach may be appropriate when introducing a software system to different areas of the organization. When upgrading an operating system, for example, the IT department may perform the upgrade on a department-by-department basis according to a published schedule. In this case, a target date for each department would be set to allow each department to plan for the upgrade accordingly. A phased approach may also allow the project team to learn from its experiences during the initial implementation so that later implementations run more smoothly.
Although the phased approach may take more time than the direct cutover approach, it may be less risky and much more manageable. Also, overly optimistic target dates or problems experienced during the early phases of implementation may create a chain reaction that pushes back the scheduled dates of the remaining planned implementations.
Table 12.1 provides a summary of each of the three implementation approaches discussed.
IMPLEMENTATION PROBLEMS CONTRIBUTE TO FEDEX PILOT'S STRIKE
A new scheduling system at Federal Express got its pilots so riled up that it may have been a major reason for them to go on strike. Although the packaged software was installed successfully at several other airlines, the problem appears to have been the up-front planning process. Tony Hauserman, communications chairman for the 3,200-mem-ber Pilot Associate Union, said, "The system was extremely disruptive, we weren't consulted before it was implemented and they said they'd run parallel tests on it before it went live—but they didn't." In fact, the poorly implemented system has helped to bring the union members closer together as the company and union were in the midst of contract negotiations. A spokesperson for FedEx explained that the system didn't "roll out the way we wanted to," but added that the company was addressing the problems pointed out by the pilots. Interestingly, TWA uses the same system but tested the system for a year before it was turned on. Moreover, TWA engaged representatives from the pilots' union from the beginning and performed parallel testing as well. The problem at FedEx, however, was that the system utilized a flight schedule optimizer that could string together the most efficient routes and schedules that would allow the pilots to get out of and then back into their home airport. Unfortunately, the FedEx pilots were caught off guard because the past union contracts were not written with strict enough rules about layovers, route preferences, and time away from home. As a result, high-tech software can make negotiations between employees and their companies more complex.
SOURCE: Adapted from Stewart Deck, System Implementation may Contribute to Pilots' Strike at FedEx, Computerworld, October 26, 1998, http://www.computerworld.eom/news/1998/story/0,11280, 33157,00.html.
Table 12.1 Comparison of Implementation Approaches
Direct Cutover Parallel
Implementation can be quick Can be risky if system is not fully tested
Provides a safety net or backup in case problems are encountered with the implementation of the new system Can increase confidence in the new system when output of old system and new system is compared Takes longer and may cost more than direct cutover approach Places more pressure on the users of the system
Allows for an organized and managed approach for implementing system modules or a system/upgrades in different departments or geographical locations Experience with early implementation can guide and make later implementations go more smoothly
Takes longer and may cost more than the direct cutover approach Problems encountered during early phases can impact the overall implementation schedule
As the end of the project draws near, everyone may become anxious to finish the project and move onto other things. Unfortunately, there is often a great deal of work that still needs to be completed. Delays or unanticipated problems may require additional time and unbudgeted resources, leading to cost and schedule overruns or extra unpaid effort, especially if an implied warranty exists (Rosenau 1998).
During the final stages of the project, the project team may be faced with both time and performance pressures as the project's deadline looms in the near future. On the other hand, the sponsor or client may become more concerned about whether the time and money spent on the project will reap the envisioned benefits. The project manager is often caught in the middle attempting to keep the project team happy and on track, while assuring the project sponsor that all is well.
Was this article helpful?
What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.