In the early days of computing, it was not unusual to find a software developer spending half of his time to write a program, and other half in making it operate faster.

Everything has changed with interactive computing. The factors that can cause performance to become a concern are factors involving interactions. The slowest thing computers do internally is to talk to internal storage, such collections of data.

Performance problems seem to be accompanied by reliability problems. Both runaway projects had mixtures of the two; in the MCC (Microelectronics & Computer Tech. Corp.) and CAD (Computer-Aided Design) project, the dominant problem was the performance; however, in the NCR Warehouse Manager Project it was hard to tell which of the two was more problematic.

For the MCC CAD project:

For the NCR:

NCR renamed AT&T Global Information Services after its 1991 acquisition by AT&T Corp., now concedes that Warehouse Manager was a disaster and stopped selling it several years ago. In defending the cases still pending, the company denies responsibility and blames a flawed application program it licensed from Taylor Management Systems. Taylor’s representatives blame NCR’s operating systems. Meanwhile, customers such as Mr. Hopper still are digging out from the record-keeping mess Warehouse manager created.

            Problems:

• In fact, although the Warehouse Manager software package, developed by Taylor Management, was indeed a success at 200 locations, it was working on another operating system, not NCR. Taylor would be responsible for converting the software and maintaining the final package. But how well would work wasn’t clear.
• Operators at different terminals would find that when they tried to get simultaneous access to the central computer, both their terminals would lock up. (Deadly embrace). The only solution was to log off and log back again. But when the terminals went back online, the information stored in Central Computer came back altered. (Silent death)
• The most damaging problem stemmed from huge gaps between what the computer told Hopper Specialty was in stock and what was actually there.
• Customers went elsewhere and the largest contract cancelled.
• NCR is relying on its so-called Universal Sales Agreement signed by Ms. Irwin, the Hopper office manager, to limit damages. Hopper claims that Warehouse Manager cost it $4.2 million in lost profit, but the Universal Agreement caps damages at the cost of the computer.

CHAPTER 3 SOFTARE RUNAWAY REMEDIES

3.1 Risk Management

Jones provides some information about the risks he identifies.

1. Inaccurate Metrics: Metrics are the measurement of various attributes of a project. There are always bad as well as good things to measure, and bad and good ways of measuring them.
2. Inadequate measurement: Twin to item 1, which concerns poorly chosen measures.
3. Excessive schedule pressure: Poor planning/estimation is one of the prime causes of excessive schedule pressure where the project developers are given insufficient time to do their job correctly.
4. Management malpractice: He points a finger at academe for this problem, saying that it provides inadequate education for software project managers.
5. Inaccurate cost estimating: Bad Planning/Estimation from the point of view of cost.
6. Silver Bullet Syndrome: Management innocence, Jones says, allows them to place too much unwarranted on new solution approaches, breakthroughs (Tech. New to Company).
7. Creeping user requirements: Requirements, the definition of what the system to be built is to do, changes during the course of a project.
8. Low Quality: Unreliable product.
9. Low Productivity: Software producers generate a software product at a measurably slow rate.
10. Cancelled Projects: When he speaks of managing the risk of cancellation, he is actually speaking of the risks of huge projects.

3.2 Isuue Management

Issue management works best in a climate of openness and helpfulness. That is, for issue management to work well, technologists must feel to open to discuss issues with their managers as they arise, and the managers must demonstrate that they are capable of helping resolve the issues that are brought to their attention.

Issue management alone is insufficient. Managers must also oversee the development process and the emerging software product. There is management approach that those who mange by issue can utilize, because they are extremely project specific.

1. Fortunately, there is a guidebook that suggests this taxonomy of issues:
2. Schedule/progress (this is where “management by schedule” comes in, but as an issue)
3. Resource/Cost
4. Growth/Stability
5. Product Quality (where managing the product comes in)
6. Development Performance (this, growth/stability, and resource/cost subsume process)
7. Technical adequacy

3.3 Remedies Attempted During Runaways

1. Extending the Schedule (85 Percent):  It suggests one or perhaps two things-either the productivity has been too low, or the original schedule was too ambitious. If there was a substantial reason for setting the schedule in the first place, then this remedy may be an exceedingly painful one. If the schedule somewhat was arbitrary in the first place, then it is easy.
2. Better Management Procedures: It suggests that inferior management procedures were used on the project up to the point of applying the remedy, and that in turn causes one to wonder why that happened.
3. More People: Adding more people makes it even later, according to Brooks. The reason that happens, of course, is that integrating new into a project adds training and learning-curve costs, and diverts the present project participants from their assigned tasks in order to accomplish such training and learning curves. If the people added happen to be knowledgeable and experienced, then the new people can “the ground running”.
4. More Money: More money can be spent on a runaway without extending the schedule- adding resources, in the form of people or equipment or outside services. In fact, no matter what remedy approaches are taken, they will usually result in spending more money.
5. Pressure on suppliers by withholding the payment and 9. Pressure on suppliers by threat of litigation: These two remedies both imply that the runaway project was dependent on one or more outside suppliers. These are the only two remedies for which the research study provides some words of explanation. ”A remarkably high number of organizations became involved in with their outside suppliers,” the authors say.
6. Reduction in scope of Project: It is not always possible to reduce the scope of a project- that is, to eliminate requirements in order to make the task manageable. But it is always possible to postpone some requirements or features in order to meet other targets. The most of the projects in question could not, or would not, defer or eliminate any requirements.
7. New outside help: (outsourcing) this remedy automatically invokes several of other remedies such as “More People” and “More money” and “More time”.
8. Better development methodologies and 10. Change of technology used in the project: Changing methodologies or technologies in midstream may be an effective remedy, but it could also shock a project and guarantee that the runaway becomes a failure. The time to switch methodologies and technologies, I would assert, is not at midproject, but at the project’s beginning
9. Pressure on suppliers by threat of legal action
10. Change of technology used in the project
11. Abandoning the project: The only way in which this is a remedy, of course, is that it stops or rapidly slows project bloodletting, such as money and resources. But abandoning the project means returning the previous quo, which presumably was found faulty in some way, or the new project would never have started.
12. Other

3.4 Remedies Envisioned For the Future

In the previous section section we reported on the findings of that study regarding remedies attempted during runaway projects. Here, we report on what the study learned about the future plans of those companies that had suffered runaways. The companies in question proposed the following long-term solutions:

1. Improved Project Management-86 percent
2. Feasibility study-84 percent
3. More user involvement-68 percent
4. More external advice-56 percent
5. None of the above-4 percent

The first interesting fact is that the list is quite short. There were 12 remedies attempted during the runaway projects, but there are only five proposed after the fact. Some of the remedies that were attempted during the project make no sense as a long-term cure-examples would include more time, more people, more money, pressure on suppliers, or abandoning the project. Clearly these are efforts of expediency only.

Another interesting difference between the lists regards user involvement. It is seen as long-term remedy, but nothing analogous to it was tried during the projects themselves.

Perhaps the most interesting idea in the long-term concepts, falling at a strong number 2 positions, is the notion of the need for a feasibility study. But the strongest theme, running across both the in-progress remedies and long term remedies, is better project management. There seems to have been a very strong belief among these companies that project management is, and will continue to be, the prime cause of software runaways until something is done about it.
 

PART 4:  CONCLUSIONS

Software is a product built from no physical resources, a product constructed purely out of intellect, it is especially devastating to the psyche when it fails. For many of us in the software business, what we bring to the table of our profession is our intellect. We software nerds may or may not be good with our hands; we may or may not be strong enough to excel in sports; we may or may not be socially skillful; but doggone it, we are artists with our minds! And when such people have a major failure of the intellect, it is also major failure of the self.

Los Angeles may have suffered a lot of calamities. But so has the profession and it hurts.