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