UNIVERSITY OF LEICESTER

 

M.Sc. in Software Engineering - CO7206   System Reengineering

Suggest the main reason behind failure in each of these cases (set 2) (from Ref#1):

1.      This organization had a large number of independent systems that tested various aspects of the avionics for aircraft. Each of these systems worked well independently and the plan was to combine them into a large test system in which independent avionics systems could be tested simultaneously under more realistic scenarios in a real-time environment. The plan called for each of the systems to be upgraded independently and to define interface specifications to insure that all the systems would work together when completed. However, insufficient time or emphasis was placed on a comprehensive architecture to define the optimal framework into which all the independent systems would fit. In addition, the integration work was delayed due to funding cutbacks. The result was that the independent systems were upgraded without a strong emphasis on how the system would finally be integrated. As the upgrades proceeded, the independent systems became more inflexible and less amenable to change. The interfaces became further refined, but without testing of those interfaces, the chances of them working correctly declined. The end result was inevitably a system that was harder to maintain and with significantly increased total cost of ownership over its lifetime.

 

2.      A large commercial service company was in the third attempt to revitalize its system. The previous two attempts failed and had to be totally abandoned. The organization’s chief executive officer (CEO) unilaterally mandated an unrealistic schedule for completing the effort. And to follow through on the "plan," the CEO appointed the organization’s chief information officer (CIO) as the sole management agent responsible to oversee the work to completion. When the CIO eventually challenged the mandated schedule (based on the technical analyses performed by the reengineering planning team), the CEO tersely stated his position along the following lines: "If you can’t complete the effort in the time allotted, I will find someone who can." It should come as no surprise that the average tenure of CIOs in the organization (and there were a procession of them) was 12 to 18 months. The resulting lack of continuity in management oversight (and support) only served to worsen the problems.

 

3.      A large, complex organization had been in the "thinking" stage about the year 2000 (Y2K) problem for a long period of time. They had issued statements to their collaborators and customers that the problem would be solved in plenty of time. Finally, at the corporate level, the organization issued a detailed "plan" to accomplish the necessary remediation. However, the organization had a set of far-flung business units that operated in a semi-autonomous manner. Because the central administration had little control over the day-to-day operations of the business units, the plan focused on the only area in which it had direct control, maintaining a complex database of each system and the status of its Y2K remediation efforts. The corporate headquarters exerted substantial pressure on each of the business units to report its progress in status reports. However, there were no increases in budget or resources or other centralized support to deal with the problem. In addition to this "take it out of your hide" approach, the master plan did not provide for any training to define the prescribed database requirements so the business units could eliminate database ambiguities and ensure uniformity of reporting. Personnel in the business units checked off milestones in the database in direct proportion to the amount of pressure they received from the central administration. However, the reliability of the checked milestones was highly suspect. A number of the major systems were in fact fixed and tested at an early date. However, it was still not clear at the beginning of 1999 whether the numerous less critical systems would survive or fail during the coming year.

Ref#1 John Bergey, Dennis Smith and Scott Tilley, Nelson Weiderman and Steven Woods. Why Reengineering Projects Fail, Tech. Rep. CMU/SEI-99-TR-010, Software Engineering Institute, Carnegie Mellon University, April 1999. 25