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). 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.
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.