A large organization needed a new system to replace its old customer data¬ base within 18 months. The new customer system was built at an estimated cost of $1 million and installed by the company’s internal information systems staff. One impor¬ tant feature of the new system was that it needed to differentiate among customer lev¬ els and provide appropriate products and services on demand.

The good news was that the system was delivered on time. The bad news was that the system did not work properly. Although it could handle normal transac¬ tions, complex transactions were error-prone. Some transactions were canceled and others were put on hold. In addition, the new system could not differentiate among customers.

Finally, the database was shut down and transactions were processed manually. New IS management was hired to build a new system and mend the strained relation¬ ship between the operational and the IS units.

So what went wrong? IS couldn’t—or wouldn’t—say no. Eager to please top management, IS directors were confident that they could build a system that was scal¬ able, on time, and on budget. In reality, IS was unable to deliver the system. Another big mistake was confining the project to a strict schedule, with little flexibility for problems and unforeseen challenges. Developers only looked at the schedule and never spoke up about any glitches they saw along the way. More than a dozen people (including the CIO) lost their jobs because of their roles in this disaster.

Required

a. What could the IS directors have done differently to help this project be successful?

b. What in-house development issues are demonstrated in this case?

c. How could the in-house issues you identified have been addressed to prevent the system failure?