Reference no: EM13946105

Consider the following hypothetical scenario. A hypothetical company has grown substantially using an acquisition strategy. As new companies were acquired, new systems that those companies were using were also acquired. At this point, this company has "one of each" of the core, production system (this could be an ERP, HR/Finance, manufacturing, or any other enterprise-level system.) It is clear to everyone that over time following this strategy created many problems and inefficiencies.

The new CIO and his biker buddy the COO decide to form a Steering Committee to clean up the mess. They involve the key decision makers from their respective organizations and get the commitment from Senior VP of Marketing. The CIO and the COO make it clear that they are the executive co-sponsors of this effort.

The Steering Committee commissions the feasibility study and determines that consolidation of the systems will result in significant operational, support, and licensing savings. It determines that many positions will no longer be needed. It also determines that none of the existing systems are year-2000 (Y2K) compliant.

Meanwhile, the Steering Committee participants spread the word around to their rank and file, and although systems consolidation will mean that positions will be lost, most people feel that "it was about time someone did something about the mess."

The Steering Committee next commissions a market survey to determine commercial availability of a replacement system. Three months are budgeted for the market survey. A consultant is brought in to draft a SRS based on the composite features of the existing systems, new requirements, and Y2K compliance requirements. Working closely with the Operations staff and Information Systems staff, and consulting with the Marketing, the consultant develops the SRS and a request for proposal (RFP). RFP is fielded, responses evaluated, a vendor selected, and a contract negotiated. The project plan for the systems consolidation and replacement is organized into several phases roughly approximating the lines of business. The overall project plan budgets nine months and is scheduled for completion with about three months to spare before the clock strikes midnight on December 31, 1999.

The project is off to a slow start, but the co-sponsors personally "drag" some of the reluctant decision makers to the now regular weekly Steering Committee meetings. Actually, the two sponsors participate in all Steering Committee meetings to ensure that issues are identified, defined, and addressed, and that the necessary resources are made available. Many, many problems are encountered; too numerous to list here. The problems range from the vendor misrepresenting some of the capabilities of the system, lack of certain required functionality, performance issues, platform instability, and on and on...The Steering Committee organizes many swat teams and slowly all issues are overcome: some through fixes and some through workarounds. Almost everyone within the company is aware of this project, and many of the staff are invited by the Steering Committee at one time or another to provide their input to solving some of the issues and problems. Although there appears to be some communication redundancy, overall everyone is "kept in the loop" well and timely.

So how does this hypothetical story end? The project goes over budget and beyond the schedule, but not by much. The expected efficiencies are obtained, although it took a little longer than planned. Some positions are eliminated, but there were no surprises and many were able to transfer elsewhere within the company. Everyone who participated in the project learned a lot.

Would you say that this was a well-managed or poorly-managed system implementation? Identify and discuss at least three specific elements that make it a well-managed or poorly-managed implementation. Be sure to explain why and be specific.