Whisler Industries: How can we salvage this project?

As manager of system development since early 1990, Paul Olafson had inherited a project from his predecessor and had not succeeded in turning it around. Whisler had a broad product line of different building materials, including certain types of semicustom tiles, moldings, and flooring. It sold both to distributors and retail stores. The project was an attempt to develop an integrated system that salespeople could use for entering orders, negotiating discounts for multiple products ordered simultaneously, and making delivery commitments. This project was seen as an important way to provide better service to customers and increase sales. The project had encountered many problems:

A key departure. In 1989, during negotiations about system functionality, the lead analyst accepted a job with a 25 percent salary increase from a competitor.
Accommodation to the departure. The new lead analyst came to an informal agreement about the scope of the project and told his staff to start working on the data structure and program design.
Change in scope. Late in 1990 Whisler acquired one of its competitors and began to work through distributors for the first time. Olafson informed the heads of information systems and sales that this would make it necessary to go back to the drawing board because the data structures and basic logic of the system would have to be changed. They responded that delays in this crucial system were unacceptable.
Divide and conquer. Fearing demotion if he made a big fuss, Olafson decided to break the project into two parts. The first part would be the completion of a system that only satisfied the needs of sales to retailers; the second part would expand that system to include additional functions needed for sales to distributors.
Another departure. At this point, one of the two lead programmers quit. Already working 50 hours a week, he thought it was impractical to try to retrofit one relatively untried system to two sets of requirements.
Dissension in the ranks. This departure led to a near revolt of the programming staff. The programmers insisted on an absolute freeze on the specifications for the system to avoid continual rework to accommodate shifting goals.
Refusal to freeze the spec. The head of information systems decided it was unacceptable for the group to produce something that was not what the internal customer wanted, especially in a firm priding itself on customer service.

At this latest development, Olafson concluded that the current project would surely crash and burn. He decided it was time for a heart to heart talk with his wife and two high school age children. He felt he was in an impossible situation. He could probably keep his job because he now had the best understanding of how the company's systems supported the sales and order commitment process. But his job was no joy and he was ready to go somewhere else, even at substantially lower pay, before he went crazy in this situation.

Questions:

1. Compare the analysis and development process thus far with the traditional system life cycle.

2. What might have been done earlier to prevent the project from getting to where it is now?

3. Explain whether you believe the refusal to freeze the spec is a betrayal of the people working in the IS Department.

4. What should Olafson and the head of information systems do?

Back to Useful Cases from Previous Editions

Main Page About the Book Student Resources Instructor Resources Contact Us