If We Build It, They Will Come: Designing Information Systems That People Want to Use
Building an information system that works is an activity that is far from certain. Even experts sometimes run afoul of the technical and project management challenges in system development — a fact underscored by American Airlines and its partners’ recent failure to deliver the Confirm travel reservation system. Failures like these are surely regrettable, but much more disturbing are failures that occur when people do not use systems that work well technically.
Our belief is that technically successful, but unused or underused, systems cost U.S. businesses millions of dollars each year. A company that has paid for an unused information system has made a very bad investment: it has not solved the problem or exploited the opportunity for which the information system was intended; it has wasted all the resources that went into developing or acquiring the system; and it has forgone the benefits from alternative uses of these resources. Thus, preventing unused systems can make a crucial difference in whether firms achieve real payoffs from their investments in information technology.
Many potential causes of systems that are not used are preventable. Unused systems are generally attributed to one of two factors: “software usability” — often called user-friendliness — and “implementation” — the efforts of line managers to ensure that the system is used. While software usability and line managers’ behavior in implementing it are very important matters, many systems’ lack of use is actually caused by a third major and preventable factor — bad business system design.
Our argument is simple: the way in which organizations build systems can be seen as a business process and examined using the same principles of business process reengineering that have achieved radical performance improvements in many operations. One of these principles holds that optimizing a part of a process — a functional specialty, for instance — can result in less than optimal performance for the process as a whole. This suboptimization can often be seen in manufacturing firms when technically excellent engineering departments produce new product designs that are not easily manufacturable.
Similarly, many information systems have not been designed for implementability. In extreme cases, no amount of managerial attention and effort can succeed in bringing about system use. Because use is not built in, these systems never achieve their true potential for improving organizational performance.
References
1. Details of this case study can be found in:
M. Keil, “Managing MIS Implementation: Identifying and Removing Barriers to Use” (Boston: Harvard Business School, unpublished doctoral dissertation, 1991).
2. D. Leonard-Barton, Harvard Business School, personal communication.
3. T.H. Davenport, M. Hammer, and T.J. Metsisto, “How Executives Can Shape Their Company’s Information Systems,” Harvard Business Review, March-April 1989, pp. 130–134.
4. R.L. Ackoff, “From Mechanistic to Social Systemic Thinking” (Cambridge, Massachusetts: presentation at the 1993 Systems Thinking in Action Conference at MIT, available from Pegasus Communications, 1993).
5. R.I. Benjamin and E. Levinson, “A Framework for Managing IT-Enabled Change,” Sloan Management Review, Summer 1993, pp. 23–33.
6. M.L. Markus, Systems in Organizations: Bugs and Features (Marsh-field, Massachusetts: Pitman Publishing, 1984);
J. Grudin, “Why CSCW Applications Fail: Problems in the Design and Evaluation of Organizational Interfaces” (Portland, Oregon: Proceedings of the Conference on Computer-Supported Cooperative Work, 1988), pp. 85–93; and
M.L. Markus and T. Connolly, “Why CSCW Applications Fail: Problems in the Adoption of Interdependent Work Tools” (Los Angeles: Proceedings of the Conference on Computer-Supported Cooperative Work, 1990), pp. 371–380.
7. T.H. Davenport and J.E. Short, “The New Industrial Engineering: Information Technology and Business Process Redesign,” Sloan Management Review, Summer 1990, pp. 11–27;
T.H. Davenport, Process Innovation: Reengineering Work Through Information Technology (Boston: Harvard Business School Press, 1993);
M. Hammer, “Reengineering Work: Don’t Automate, Obliterate,” Harvard Business Review, July-August 1990, pp. 104–112;
M. Hammer and J. Champy, Reengineering the Corporation: A Manifesto for Business Revolution (New York: HarperBusiness, 1993).
8. D. Leonard-Barton, “The Case for Integrative Innovation: An Expert System at Digital,” Sloan Management Review, Fall 1987, pp. 7–19; and
R.B. McKersie and R.E. Walton, “Organizational Change,” in M.S. Scott Morton, ed., The Corporation of the 1990s: Information Technology and Organizational Transformation (New York: Oxford University Press, 1991), pp. 244–277.
9. R.M. Rubin, “Organizational Simplicity: Reaching Beyond Business Re-Engineering,” SIM Executive Brief (Chicago, Illinois: Society for Information Management, Fall 1991).
10. J. Grudin, “Systematic Sources of Suboptimal Interface Design in Large Product Development Organizations,” Human-Computer Interaction 6 (1991): 147–196; and
R. Dagwell and R. Weber, “System Designers’ User Models: A Comparative Study and Methodological Critique,” Communications of the ACM 26 (1983): 987–997.
11. The true “consultant” is neither a “pair of hands” who does only what the client wants nor the “technical expert” who makes all the decisions. See:
P. Block, Flawless Consulting: A Guide to Getting Your Expertise Used (San Diego, California: Pfeiffer, 1981).
12. Benjamin and Levinson (1993).