CUNY B r o o k l y n  C o l l e g e            Department of Computer and Information Science
CIS 763X: Software Methodology
with Dr. D. Kopec                           Fall, 2000


Back tondividual Class Presentations
Software  Runaways

by Bill Glass

Chapter 2.3:   Technology New to the Organization
Chapter 2.4:   Inadequate/No Project Management Methodology

Presented by Peng   Li


My presentation tonight is about some cases in software runaway.

 As we know, software is more and more controlling our social life right now. Though it’s human being who develop or invent software, can human being control the software behavior successfully and completely? The answer from me is definitely “No!”.  Did human being just develop its own nightmare? Maybe or maybe not, I think we don’t know that yet. We have a lot successful cases to show that software is friend of human. But can we better control software in order to serve people better? Yes! That is why we should always analyze and study the runaway cases, write reports, books, articles about then.

 It is all known that software failure is not only the failure of software itself, but there are always many other factors to influence that, which includes: operators, technical support, management, environment, maintenance, hardware, training, documentation, communication or human being ourselves, etc..  We have to know how to develop software, how and who to use it, when and where to use it. Software failure is not a simple thing to just blame someone, we have to find out the truth behind the failure and then to improve it, not let that happen again. Just as Dr. Brooks said: “two steps forward, one step back.” For my personnel opinion, we just can’t prevent software failure, but we do can reduce the cost caused by the failure.

 The following is the analysis of some runaway cases and let’s see what we can learn from them.
 

1. The FoxMeyer Case

 The first case we now look at is a company called FoxMeyer Drug Co., which filed bankrupt-court protection in 1995. The reason behind it is because of the failure of their new advanced multimillion-dollar computer system.
 
FoxMeyer was the fourth-largest drug wholesaler in our country. In the early 90’s, they tried to adopt new technology to be more competitive in the market. Of course, the technology can reduce cost, speed up inventory, improve the ordering system and satisfy their customer. The high level management saw the risk that if they couldn’t come up with it, the company would lose tremendous share of the competitive market. So, they pushed the project.
 
In 1994, after rounds of negotiation and consulting, FoxMeyer decided to choose SAP software, a leader in Information System Technology.  SAP gave great effort to develop such kind of large client-server system, though this kind of SAP product never being used by high volume process before. (FoxMeyer had about 500,000 items each day at that time.) Since it was so large, testing was in major difficulty, simulation was inadequate, and they just couldn’t generate such amount of transaction to do that. At this critical moment, the highest level management brought more bad news for the team of SAP: FoxMeyer signed a huge contract and need to begin delivery soon. For SAP, it meant that no more time to make software more stable, more efficient, no more time to customize, no more time to study the design and make more test and simulation. For the management of FoxMeyer, they thought if they gave enough pressure, the system would be up on time, they pushed the project. Well, the reality is that if the new system won’t be up, the old system just can’t take the full load of all supplements.
 
After SAP’s great effort, they did it on time. Now the big mystery is: can the software hold on? Well, disappointingly, no.  The software often occurred data errors, which meant drug could be delivered to the wrong hospital, customer’s information might be wrong. That was a desperate hit to management, plus, the new designed computerized-warehouse delayed. They lost a lot customers, they also lost $34 million dollars.
 
Today, the system is good, efficient, but the damage is done. Now we can look back to see what exactly happened to FoxMeyer. The problem is complex. Every company needs big contract, but every company needs steady and efficient system to support it. We should put “steady” ahead of “efficient” since if system is not steady, nothing can be done.
 
 (1).  Management rushed the project. The system/software is a whole basket, every function, element, part counts. They have to communicate each other very well and work with each other. It takes time to complete that. By rushing it, it just has more errors, more bugs.
 
(2).  Management can not expect too much from technology, can not be too optimistic about it. Technology is just a tool, not a savior. At that time, SAP was not amateur, they just couldn’t process such amount of transaction at that speed. Though management signed a breakthrough deal, the technology didn’t. Management should always leave room for the development of system. Rushing it just rush into disaster.
 
(3).  SAP doesn’t do enough test on the new software and they released it.  Software should be designed, developed and tested step by step. There is no “big leap” in software development.  FoxMeyer needed 500,000 transaction each day, they knew it but they just couldn’t find a better way to finish it. SAP had no experience on that kind of system. Trust is one thing, reality is another thing. So next time when we give our fate to some inexperience people, we should think twice.


 We have lot cases on software runaway these days since software stepped into out life so deeply and widespreadly. That is why we need be more careful to examine and exploit it.
 
Like in 1984, NJDMV tried to adopt the new technology—4GL(4th generation language), which at that time almost no one used it to build a large comparable system yet.  After NJDMV finished the project, they found themselves in a big hole. (1) 4GL was incapable of creating batch programs to update overnight. It collapsed.  (2) 4GL couldn’t provide good index processing, police office’s search was delayed for a longer time. (3) 4GL’s computer-to-computer interfacing was not good enough, other agency had difficulty to access the data. How did this happen? Well, just usual drill, 4GL was not enough tested; the project leader didn’t have any data processing experience; NJ government insisted the project delivered on time due to some fund raising and political reason.

IRS had familiar problem in 90’s. Their failed new Tax System Modernization (TSM) project cost taxpayer’s almost $4 billion dollars. Why? The outsourcing was not aware of the operation of IRS; not familiar about the forms and applications. Also IRS failed to develop an overall architecture; failed to redesign the whole process. The congress gave them the following comment: planed badly; contracted badly; built badly. Another important matter I want to point out: during those years, there were three commissioners, two deputy commissioners, some republican and some democrats, but they untied by same thing: no technology background. If the leadership of the agency have no idea of what the software will go, they will go nowhere.

 Sometimes, we can develop our own product, sometimes, we can buy them from the market. What is the rule? Let’s see another example first.
 
In 1988, Australia’s largest bank Westbank announced with pride and honor and energy that they would develop their own new advanced system, CS90. In the blueprint, there are fancy words, functions and abilities like they are on top of the world. They had five years to accomplish that with $85 million dollars budget. Enough money, enough time. So let’s fast forward to the result situation: nothing showed up on time with even spending doubled, with $150 million dollars. The joke was that they cut off 500 computer jobs to save about $37 million dollars per year. What was wrong to them? In their proposal, there was a beautiful word: configure the necessary application system from these components using knowledge engineering techniques. What’s knowledge engineering techniques? Even they themselves were not so sure. So later they contacted IBM for some ideas. The “think tank” had a lot to share but with different approach. So did they want to change direction in the middle of race? They couldn’t!  In 1992, the project suffered total loss, the Westbank lost total $1.66 billions dollars for that financial year!
 
Actually, they could buy some familiar product from the market, stable and useful. They went into a hole and hit themselves half dead for the development. Why took that kind of risk for such kind of large company? I just can’t imagine that when the first version of window3.1 came out, I can’t see which major company choose to use it right away. Why not? No need to take that kind of risk. They have steady customer, steady market, and steady system. If the customer switch to your competitors, it won’t be easy to persuade them to come back.
 

2. Bank of America case

Large companies usually do better when developing the system. Bank of America has rich history of technology success. But in 1988, they got a very good lesson for current technology, large company get to be more careful when dealing with it.

In 1980’s, Bank of America’s (BOA) business was in low tide. Sooner, the new elected president found an idea to take them out of it: BOA needs a new modern operational system and technology leap, Masternet, so they could stay in the lead. Saying is easy. Under such circumstances, to reduce the risk, they decided to fix one department first. So in 1982, the journey began. Six years later, in 1988, the last chapter was closed. The system was far more than disappointing: $80 million dollars loss, the whole then-profit trust dept. was sold to another company. The curtain of dreaming new system dropped.
The reason for the loss was sophisticated. Let’s state it as following:
 

(1) Financial risk  During the time of development, BOA was downward in doing business. They expect the new system to bring them new customers and profit. But the reality was that they were losing money those years. They had a plan to spend $5 billion dollars to extend their business. The risk was too high for them. Setting up a major project at this time with such high expectation was not wise. Software development should follow the company’s overall performance. At that time, BOA could not afford such amount of loss. But Masternet should handle billions of dollars of client assets. If Masternet failed, the bank would have nowhere to go.

(2) Technology risk      the technology at the time couldn’t meet the requirement of that project for the trust automation challenge. In order to complete the new software, more time and fund were needed. BOA wouldn’t like to do that. They wanted to finish it as soon as possible so the client could use Masternet to invest. But the software should cover platform, transfer, telecommunication network,  etc..  It was hard to say.

(3) Project risk         A. The high level management couldn’t understand the complex, sophisticated project, confusion leads to misdirection and wrong orders.    B. They hired like several “surgical team” as consultants. Each team had their own opinion and version. This is against the famous saying by Dr. Brooks “system is a product of one mind”.    C. The merge and occupation of other companies affect the project. Over years, the project should always meet the change of business, thus lost concentration.     D.  Resistance from inside organization. Since the system would upgrade from batch processing to real-time online processing, employee training is another major issue. The high level management should stand side by side with technology. Every employee must learn from use the new system.

(4) The project had to meet different requirement from different groups.  Customer service, sales, agents, departments, consultants, administration, even government regulations, all should be taken care of by the software. The develop team just couldn’t focus on technical problems. The leadership should coordinate all groups, functions, pay enough attention.


Bank of America gave us a good example that project is not a simple
issue in any organization. There are many factors can affect the success of software. Behind every success of implementation of software, there is always failure. There is an old Chinese saying “ if you often walk along the river, you will get your shoes wet.”  Well, nowadays, we have to walk along the side of software technology since it is everywhere. So how can we try not to get out feet wet? Careful planning, careful implementation, careful maintenance. From my own opinion, we will  get shoes wet anyway but we can try to limit and control the damage. If the damage is acceptable, we can consider it.  We can’t always stay with the same software, on the other hand, we can’t do it too fast and too much. We should take the balance and safer way. Software can save and help us, but it also can hurt and destroy us. So we have to make full preparation and analysis for it anytime.
 
 
 

Reference:

William Bulkeley,   Wall Street Journal,  Nov. 18,1996
David Kull,   Computer Decisions,   Feb.11, 1986
Robert Glass,    Software Practice,  Nov. 1992
Gary Anthes,    Computerworld,  Oct. 14,1996
Joseph  Maglitta,    Computerworld,   Oct. 14, 1996
Jeffrey  Szilagyi, Garry Hector,   Breaking the Bank
Tom Anderson, “MasterNet-A technical Postscript”, The Financial System,  Journal, Vol.1, No.1 (April 1998)
BankAmerica Corporation 1986 Annual Report,
Fred Brooks, Addison-Wesley,  the Mythical Man-Month
Michael Robinson, “BankAmerica is Computing More Trouble”, “BankAmerica Fires Two Over MasterNet Problems”,
 American Banker, July16, 1987; Oct. 22, 1987
Jonathan Levine, “Bank of America Rushes Into the Information Age”,   Business Week, apr.15, 1985
Douglas Frantz, “Computer: Bank Slips in Bid to Leap into 1990s Technology,”  Los Angeles Times, Feb.7, 1988
 
 


Comments and suggestions e-mail to Sergey D.