Successful Reengineering Demands IS/Business Partnerships
Topics
Breezy Services Company, a medium-sized service provider, was in trouble.1 New entrants threatened its domination of particular market segments, and competitors attacked its customer base. Its business practices and information systems infrastructure were decades old, and there was little hope of enhancing the company’s existing (or legacy) systems to support innovative products or services. And, although the company was still viable, its profit margins were shrinking.
Breezy’s top management decided to undertake a massive three-year business reengineering effort that would involve all business functions and include an extensive information systems (IS) project to technologically enable radical business change. Breezy executives expected the project to achieve orders-of-magnitude improvement in both operations and customer service. After initial analysis, selected business managers organized into teams structured around a newly defined reengineered business model.
IS also mobilized to support the business reengineering effort. After Breezy hired a new CIO from an external pool of candidates (and removed the incumbent CIO from the IS operations), the IS staff thoroughly assessed the company’s existing systems and IS employees’ skills and reorganized to focus on new technologies and operate parallel to the business reengineering teams. The department also introduced a new system development methodology and developed prototype systems to support business reengineering efforts using client/server technologies. Finally, the IS staff began to develop a comprehensive, long-term IT strategy designed to create an IS organization that would provide ongoing reengineering support.
Despite some earnest determination, however, the reengineering effort was only marginally successful in bringing about holistic, broad-based change. The reengineering teams found that making progress in the early organizing and creative analysis stages was easy and quite exciting. However, the later work of prototyping, experimentation, design, development, and implementation of new business models was much more difficult. In particular, they were surprised by the degree of organizational resistance they encountered, the complexity of maintaining quality communications with those outside the reengineering teams, and the difficulty in knitting together a working business model agreeable to all the constituencies on the reengineering teams.
The IS organization had mixed results as well. IS was able, for the first time, to introduce and support new client/server technology that incorporated server-based relational databases and client graphical user interfaces (which the business users embraced wholeheartedly). And IS did make permanent improvements in some legacy systems to support the new reengineered business model.
References
1. “Breezy Services Company,” used as one of the cases in this article, is an amalgam of two separate companies. The author has firsthand experience working with these companies’ IS departments in their efforts to support business reengineering.
2. M. Hammer and J. Champy, Reengineering the Corporation (New York: HarperBusiness, 1993), p. 31.
3. J. Maglitta, “One on One, Michael Hammer,” Computerworld, 24 January 1994, p. 85;
B. Caldwell, “Missteps, Miscues” Informationweek, 20 June 1994, p. 52; and
CSC Index, “State of Reengineering Report” (Cambridge, Massachusetts: CSC Index, 1994), p. 7.
4. Hammer and Champy (1993), p. 44.
5. Ibid., p. 208.
6. E. Martinez, “Avoiding Large-Scale I/T Project Failure: The Importance of Fundamentals” Project Management Journal, June 1994, pp. 17–25.
7. B.H. Boar, Implementing Client/Server Computing (New York: McGraw-Hill, 1993), pp. 171–173. This is just one reference to the often described organizational resistance to new technologies.
8. PMI Standards Committee, Project Management Body of Knowledge (Upper Darby, Pennsylvania: Project Management Institute, 1987), pp. H1–H7. The communications management section outlines such a communications function and plan.
9. W.S. Humphrey, Managing the Software Process (Reading, Massachusetts: Addison-Wesley, 1990), pp. 83–92.
10. The author is indebted to Phil Lawrence, a vice president with CSC Index, for introducing the concept of the IS organization demonstrating leadership by championing the company’s technical agenda.
11. This article does not dwell on the subject of information technology architectures and the merits of their development. The reader may wish to review the following two publications as well as other literature on the subject. The first citation is suited to the practitioner; the second is more suited for management.
J.A. Zachman, “A Framework for Information Systems Architecture,” IBM Systems Journal 26 (1987): 276–292;
G.M. Hoffman, The Technology Payoff (Burr Ridge, Illinois: Irwin, 1994), pp. 47–59.
12. For a timeless article, originally published in 1959, see:
P.O. Gaddis, “The Project Manager,” in Managing Projects and Programs, ed. N.R. Augustine (Boston: Harvard Business School, 1989), p. 154.
13. P.F. Drucker, Management: Tasks, Responsibilities, Practices (New York: HarperBusiness, 1993), p. 128.