Individual Class Presentation Fall 2000

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 to individual Class Presentations Software Runaways.
Lessons Learned from Massive Software Projects Falure

by Robert L. Glass

Chapter 2.5: Insufficient Senior Staff on the Team

Presented by Sergey Doubov

INTRODUCTION

In “Software Runaways” Robert Glass continues a discussion about complexity of large-scale software production. He analyses problems of this field reviewing life examples of the past. Chapter 2.5 of the book is devoted to idea of how proficiency and “quality” of senior and management staff is important.

Similarly to Brooks “The Surgical Team” chapter, Glass starts discussion with research studies, which show that capabilities of software workers differ by factors from 5:1 to 30:1. In the book, these people are named by broad term “senior staff”. Having capabilities and experience, the senior staff makes a difference between good project and bad, between success and fail. Two short articles clearly show how “insufficient senior staff on the team” could make large scale project fail. Unfortunate experience of famous Adidas Corporation was not as clear as development of CONFIRM reservation system by AMR. However, it opens a story of how productivity depends on quality of the people and the team doing the work.

CHRONICLES: Adidas Corporation

In 1993, Adidas faced hurting difficulties with the old distribution system that was responsible for distributing good and shipments all over the US. Lack of standards, high coordinating complexity, late orders, slow response for demand and market change were main problems with the system. As fact, Adidas was loosing valuable customers. In January, the top management approved the development of new state-of-the-art distribution system. The goal of the new system was to centralize the tracking bar coded system and tire it up to conveyors, belts, lifting equipment, chutes and scanners. The reduction of time needed for processing orders and merchandise should result in sending orders out in 24 hour. The problems with system became a nightmare when many of the key players involved with initial system lunch left company and the others were heading to exit. There was no “appropriate staff” and management will to take care of snowfall of problems. First, Integrated Software Logistic Engendering Inc., the original software vendor, went out of business. This company marketed the system to run under UNIX platform but Adidas decided to use Stratus Computers, which they were familiar with. Also, ISLE left its creation without appropriate documentation and a lot of unfixed bugs. Meanwhile, Adidas shot itself in a foot when fired its lead integrator on the project. The system ran but not well. Eventually, Adidas decided to scrap the computer software and hardware (keeping sorting equipment) and install an IBM RS/6000 server running warehouse management software from Exeter Systems in North Billerica, Mass. That was a system that brought Spartanburg facility to its knees. The business went down for 90% because of storage. Thanks to many other its warehouses and facilities Adidas had passed Spartanburg bottleneck by distributing workload among them. But it paid double price for another state-of-the-art system.

The lessons learned from Adidas Corporation experience

Never overestimate the staff training and the senior management capabilities when moving to a new system. Be prepared for big changes. This is where Brooks discussion about conceptual integrity could be mentioned.

Invest enough time in analysis and planning. Deeply investigate business processes with great care and importance. Pay attention to minor and hidden details. The planning, in turn, should take into account different changing aspects of environment. In case of difficulties and unplanned changes, prepare adequate recovery strategy (e.g. plan “B”)

CHRONICLES: CONFIRM Project Development by AMR

In 1987, another big project disaster has happened. A big software development company named AMR took an advantage of developing the most sophisticated information system, which would centralize hotel reservation all over the world. The first three partners for the joint venture were Marriott, Hilton and Budget Rent-a-Car. In 1986, after a year of negotiations three parties and AMR came to the agreement with the following objectives. The main project goals should be convenience, speed and accuracy of making reservations for lodging, air flights, and car rentals all-in-one. The cost of each transaction (e.g. reservation) would have to be reduced due to centralization. The cost reduction of a few cents per reservation should result in high profit increase, especially, on the long run.

Accordingly to these goals AMR would have

(1) to design, operate, maintain a new state of the art reservation system;
(2) to design and develop interfaces with airline computer reservation system;
(3) to market reservation system to customers for profit;
(4) convert each partners’ existing reservation systems to the newly developed system.

In accordance with the contract the project should not exceed the total expenditures for more than $55.7 million and the dead line in June 1992. Thus, on December 1988, AMR presented a base plan of the system, which was initially found unacceptable because it was “too general” and did not reflect “what user is expecting”. The next six-month of revision came out with project price increase up to $72.6 million and also stated that a price per reservation would be $1.30 (instead of the original $1.05). However, the client-partners decided not to withdraw because they would have to pay $1 million dollars as fine. During the following year while AMR assured everyone that the project was on time, it did not complete terminal-screen design on time and missed another important milestone in business area analysis phase. Moreover, some problems declared in the first phase of were redefined by developers and became a part of the next phase. In February 1990 AMR admitted that it was more than 13 weeks behind the schedule and stared another six-week “re-planning” effort. Budget and Marriott waited until the summer and expressed their concerns that the project was still behind the schedule and that its management was ineffective. In August 1990, when AMR declared the first phase complete and entered the second major phase, Marriott representatives were refused to show or explain status of project development. AMR executives claimed they would still meet the deadline. In February 1991, AMR presented a “Re-Plan” to replace an original development plan according to which only one of the partners would be able to use the system by June 1992. The other two parties were promised to receive all system features by March 1993. In addition, the price tag was changed to $92 million dollars. In the mean time, AMR forced its employees artificially change the deadline schedule. Those who were not satisfied with this decision were fired or reassigned to other projects. The other half was looking for another positions and started to flee the company. The project manager hired an independent consultant to evaluate the project. Dissatisfied with results, he “buried” the report. While each being charged $1 million per month, Marriott, Hilton and Budget did not believe that the project should be on time, but hoped that whatever was broken could be fixed to meet the original schedule”. However, the hope vanished when on April 1992 the major problems surfaced during the first system test. In its letter to partners, AMR admitted that the project management was inept and deliberately concealed a number of technical and performance problems. While skilled, the technical staff failed in construction of very demanding interfaces between the system and the extensive database. The original senior staff was fired and replaced with new people. It did not saved the project and after 3.5 years and $125 million dollars spend the tree-partner consortium disbanded.

Technically, the developers claimed that the main problem was integration of the central transaction-processing system and decision-support system. They both were not integratable!
Apparently, the failure due to the bad management practices not only by AMR senior staff but also by the management of other three partners.
Poor communication did not allow to reveal all problems and customers demands. The meetings all partner’s management were conducted just once per month. This is a deadly practice when managing development effort of such magnitude.
On contrary, AMR accused partner-clients of being “selfish” in counter suite against them. In the middle of a project Marriott, Budget and Hilton changed the approved original plan. Software vendors had to develop three different subsystems instead of one centralized system.

The lessons learned from CONFIRM failure

What did we learn from the CONFIRM project failure is that combination or one of the following reasons could fail a development of satisfactory IS:

(1) Unforeseen or insurmountable technical difficulties;
(2) Underestimation of cost and completion dates;
(3) Failure of the developers to understand the system’s requirements, or changing the requirements after the project started.

CONCLUSION

From these examples, we can conclude with principles for three major parties: managers of the service provider, employees, and clients. With these principles much of the damage in CONFIRM and Adidas-like cases can avoided.

Principles for Managers of the Service Provider:

1. Be realistic and include enough “slack” time when outlining the project schedule. Technical and other problems may occur. You know when you start but you do not exactly know when you finish. Short schedule is not only unrealistic, but and unethical, too.
(mention Brooks “cooking takes time Ch.2 and Thurm)
2. Never proceed to another phase until problems are solved in the preceding phase.
(mention AMR’s case)
3. Executives should not make “calming” statements. This practice leads to no client’s trust, unethical, and sends wrong signals to employees.
4. Adopt a Code of Professional Standards and communicate to your employees. Clear up the sharp topics like unresolved problems, when alert management, what to do “if” and etc.
5. Most important: be honest to your client. Otherwise, it may hurt you and your company. Your employees would have a bad example and will lie to their supervisor.

Principles for Employees:

When you realize a persistent problem, notify your supervisor. Employees are those who first observe technical problem.

Principles for Clients

1. Check the status of a project periodically. Do not rely just on developer’s previous experience. You project is different. (mention Marriott management fail to insist)
2. Communicate to the developers exactly what your requirements from the new system are. Realize, that the later modification could cost and the deadline postponed.
3. Pay attention to alerting signals. When executives and other employees of the developer massively dismissed or voluntarily looking for new positions, ask questions.

In conclusion, large development projects rarely proceed exactly as they planned. That is why management should be deeply involved in the progress of large–scale projects.

References

Robert L. Glass, Software Runaways. Lessons Learned from Massive Software Projects Falure, Prentice Hall, 1998

Comments and suggestions e-mail to Sergey D.