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. When this occurs, the root cause is often the same as that leading to unmanufacturable new product designs — a suboptimized design process created by organizations’ best efforts to optimize functional parts.

We illustrate this argument with a case study of a system we’ve named CONFIG in a company we call CompuSys. First we describe how and why CONFIG failed to solve the company’s problem, despite its technical soundness and attention to “human factors.” Then we show how the system could have been redesigned to solve the business problem. Why wasn’t CONFIG redesigned in this way? To answer this question, we examine the system-building process in the same way we analyzed the case of CONFIG, and conclude with recommendations for senior managers and information systems professionals.

A Failure That Could Have Succeeded

CONFIG is an expert system designed to help the sales representatives at CompuSys, a computer company, produce error-free product configurations before quoting prices.1 The system was intended to reduce costly “allowances” in which the company had to supply hardware without charge to customers when it found that price quotations were based on inaccurate product specifications. The system “worked” — it produced high-quality configurations. But the sales reps didn’t use it, so the company’s problem wasn’t solved. System developers attributed CONFIG’s lack of use to poor interface design, hardware inaccessibility, and inadequate training and support. The company initiated a multimillion-dollar program to correct these flaws. But the sales reps did not use the redesigned CONFIG either, and the configuration error problem continued.

The Origins of CONFIG

Configuration errors have been a long-standing problem at CompuSys. The company has a business strategy of producing computer systems tailored to its customers’ needs. Because of the many components used in CompuSys’s products — CPUs, memory, power supplies, cables, disks, tapes, printers, software, and so on — a virtually unlimited number of workable system configurations is possible. At the same time, the potential for error is great: a sales rep can forget cables or mis-specify a particular component. The consequences of configuration errors are also great: when inaccurately configured systems are shipped, customers incur costs and delays in getting the system to work properly. No matter what CompuSys does to fix these problems after the fact, the company’s reputation suffers.

Over the years, CompuSys tried a variety of solutions to the configuration error problem. An early solution was “final assembly and test,” in which the components of a customer order were shipped from geographically distributed manufacturing facilities to a central site, where they were uncrated, hooked up, tested, repackaged, and reshipped to the customer. But the final assembly and test activity was very expensive, and it did not catch all the errors. So manufacturing created the new function of “technical editing” to verify the configurations the sales reps specified on sales orders before filling the order. Still later, systems specialists in manufacturing realized that an expert system could improve the technical editors’ productivity. The result was the technically successful and widely used VERIFIER expert system. Eventually, VERIFIER’s developers saw that configuration errors could be more effectively controlled at the source, in sales, thereby eliminating the need for technical editors in manufacturing. The idea for CONFIG was born.

Building CONFIG — The First Time

In many ways, CONFIG was a textbook system development project. The system was iteratively prototyped during a period of several years. Sales reps worked with developers on system design and testing. CONFIG eventually produced configurations better than those of the average sales rep. In addition, the system supplied useful and time-saving outputs such as configuration diagrams, component lists with configuration-specific comments, lists of required cables, and warning messages on issues affecting the technical performance of the configuration.

Despite these features, CONFIG was not widely used by the sales reps. A 1986 survey showed that approximately 75 percent of the company’s sales reps had tried CONFIG, but that only 25 percent were actually using it. By 1989, fewer than 10 percent of reps continued to employ it.2

Tackling CONFIG’s Lack of Use

CONFIG’s developers were not satisfied with the low level of system use, but company culture and politics did not allow implementation by mandate. CompuSys employees were viewed as professionals who could make their own choices about the tools they needed to do their jobs. The assumption was that, if an information system was good enough, people would want to use it. So the developers looked for and tried to fix inadequacies in the system. Unfortunately, the root cause of CONFIG’s nonuse lay elsewhere — in the design of the business process.

CONFIG had already demonstrated its ability to reliably produce valid system configurations, so developers knew that its lack of use could not be attributed to inadequacies in functionality — what the system did. So they based their plans for solving the problem on the results of the 1986 survey of CONFIG users, which identified “human factors” and training as key factors in system nonuse. The problems in these areas were real. CONFIG had been designed to run on shared line-printer terminals, which limited CONFIG’s accessibility. Users interacted with the software through a combination of menus and commands; they found the commands difficult to remember, and they complained of “getting lost” while navigating through its many layers of menus. In addition, training and documentation had been hit or miss, particularly since the system had changed so much during its many years of evolutionary development.

Although, as we will show, these platform, interface, and training problems were not the root cause for not using CONFIG, they were problems that CONFIG’s developers thought they could solve. So, in 1988, the developers initiated a major effort to deploy a more usable version of CONFIG. The goal was ambitious — to provide “the necessary infrastructure to ensure optimization of the configuration creation process” (CompuSys internal memorandum, emphasis added), and CompuSys committed substantial resources, both technical and managerial, to achieving it.

The redeployment project cost CompuSys a small fortune. For more than a year, a development team worked on the user-friendliness of CONFIG’s interface. Because the software of the user interface was intertwined with the logic of the expert system, updating the interface was a complex and expensive undertaking. CompuSys devoted considerable resources to other aspects of the CONFIG redeployment. In 1990, it selected five of the company’s U.S. district sales offices to test the new CONFIG interface and platform. In each pilot district, hardware and software were installed to make CONFIG readily available to sales reps while ensuring adequate response time. The redeployment plan also included on-site training for all potential users. During day-long sessions, 345 people attended lectures and handson training in CONFIG just prior to the redeployment. Providing local user support was also an important part of the redeployment strategy, so the company stationed two support personnel in each of the pilot districts.

Results of the Redeployment

A technically superior system, an improved user interface, and a textbook implementation effort — many aspects of the CONFIG redeployment project fit the information systems specialist’s recipe for success. But what was the payoff? Surveys of users conducted both before and after the CONFIG redeployment revealed statistically significant improvements in their perceptions of system availability, training, and support (see Figure 1). In interviews, sales reps commented favorably on CONFIG’s new interface. The following quote was typical:

The difference between the old and the new version of CONFIG is like night and day. I was exposed to the old version of CONFIG in sales training and I would never have used it, whereas I can see myself using the new version of CONFIG.

Clearly, the project team had succeeded in removing the barriers to using CONFIG that they had targeted in the redeployment project.

Unfortunately, the redeployment resulted in a negligible increase in the overall use of CONFIG. Reps were asked how frequently they used CONFIG, where the response choices were “never,” “used once,” “used several times,” and “used extensively.” The average response —lying between “used once” and “used several times” —hardly changed at all in the post-deployment survey (see Figure 1). Not surprisingly, the redeployment effort had no effect whatsoever on reducing the configuration error problem.

Root Causes for Not Using CONFIG

What went wrong here? On investigation, we found two reasons for the failure to use CONFIG. First, sales reps were not motivated to do what the system enabled them to do. Second, using the system made it harder for them to do what they were motivated to do. Either of these problems alone would have reduced CONFIG’s use. Together, they were fatal. And the expensive redeployment effort did nothing to address either one.

No Motivation.

Sales reps simply were not motivated to produce error-free configurations. Systems specialists in manufacturing designed CONFIG to help the sales reps prevent configuration errors that did not affect sales but did affect manufacturing. CompuSys’s organizational structure and reward systems when CONFIG was introduced did not give any incentive to the sales department to prevent configuration errors but rewarded reps on the basis of their sales volume. Individual sales representatives’ accuracy was neither monitored nor reported to them or their managers. One rep explained, “It’s not that anyone wants to be inaccurate and make a lot of errors, it’s just not something we are measured on. And we will work toward what we are measured on.”

A sales manager, asked to describe how sales reps’ performance was evaluated, said:

You won’t see anything [in the performance appraisal form] about quote accuracy. I’m not managed, nor is my manager managed, to “dirty” orders. So it doesn’t really matter. It’s not one of my metrics. It’s not a critical success factor for me or for the sales reps. There are no kudos if they get it right, no scolding if they get it wrong.

Not only was there no scolding if sales reps got orders wrong, there were no economic pressures on them to prevent “dirty” orders. The cost of allowances was not factored into the sales reps’ compensation, as one sales manager explained: “If it were somehow painful to the rep if configurations are not correct . . . that’s an organizational issue, and for some reason we don’t feel that pain.”

Because the configuration error problem was not brought to the attention of sales either through measurement systems or through explicit monetary rewards, the people in sales, from district managers on down, thought the configuration error problem too slight to warrant the effort of using a system to correct it:

We never miss the big stuff . . . CPU, etc. . . . only cables. Who cares about a $50 cable? It’s not worth the time it takes to run it through CONFIG. Ninety percent of the time, the customer will authorize a modification anyway.

Furthermore, the sales reps believed that verifying the accuracy of the configurations they specified on sales orders was not their responsibility. Although the redeployment effort removed many barriers to the use of CONFIG, it did nothing to attack the users’ basic lack of motivation or incentives, without which they were highly unlikely to use CONFIG.

Disincentives.

The sales reps actually had disincentives to using CONFIG; it made it harder for them to do what they had the motivation to do — make sales. It is a well-known phenomenon that optimizing a subprocess can often lead to suboptimizing the larger process. And this is precisely what happened with CONFIG. Its developers had the goal of optimizing “the configuration creation process.” But, from the sales reps’ perspective, creating the configuration is actually a subprocess: it is only a means to the end of the true goal — getting the customer a price quote in the course of making a sale. One rep commented, “The goal is not to generate a configuration. The goal is to generate a complete, bottom-line number. You don’t do a configuration for its own sake.”

CONFIG’s developers had a business process model that went something like this: “Before sales reps can close an order, which they will then pass to manufacturing with or without errors, they must supply the customer with a price quote. Before they can quote a price, they need to configure a system.” This model suggested that CONFIG be designed as a stand-alone configuration system. Pricing information was to be provided through a noninteractive one-way linkage to the company’s product-pricing and quote-generation system (PQS). (Developers in sales developed PQS at about the same time that manufacturing began working on CONFIG.)

Because CONFIG was implemented as a stand-alone configuration system, the sales reps who used it found it more time consuming to produce price quotes than those who did not. In making a sale, it is sometimes (maybe often) necessary to work back and forth between the system’s technical configuration and what the customer is willing to pay. This argues strongly for a system design concept in which CONFIG is fully integrated with pricing information and quote printing capabilities. A rep commented:

When you’re configuring a system, you need to play with the price in order to get the quote right. You need to balance the technical objectives of configuring a system with the customer’s constraints. . . . There has to be pricing information in CONFIG.

CONFIG users could generate an output file and import it into PQS, but this was cumbersome and did not meet their need to respond quickly to customers’ requests for quotations. One sales rep remarked:

When you get done with CONFIG today and want to print a quote, you create a file, transfer a file, you go into PQS, you import it. It’s very cumbersome. The turnaround time is way too long, so I’ve started not to use the system [CONFIG] because when I need to do a quote, generally the customer is waiting. They’ve asked for something, and you can’t wait a day or two to get stuff back.

Not surprisingly, sales reps and their managers did not see CONFIG as a tool that increased their productivity in their most important goal — making sales:

If CompuSys needs to make its salespeople more productive, I think they meant well to give us the best tools. Unfortunately, CONFIG turning us into administrators and managers rather than salespeople is hurting yields [sales volume]. CONFIG is a good tool — I just think it’s in the wrong individuals’ hands. Why should a sales rep be stuck here at the office cranking out configurations and quotes when he could be out making more sales?

So sales reps did not use CONFIG, even after the expensive redeployment effort.

Attacking the Root Causes

When the redeployment project began, there were two problems: the original configuration error problem and the nonuse of CONFIG. Believing that CONFIG’s use would solve the configuration error problem, its developers tried to solve the nonuse problem. But they misdiagnosed the root causes and succeeded in solving neither problem.

What could have been done differently here? We believe that there are three categories of solutions, each with different strengths and weaknesses — radical solutions, implementation solutions, and systems solutions. We most want to emphasize that, with a different design concept for CONFIG, developers could have solved both the configuration error problem and the problem of system nonuse at the same time. And, in order for organizations to achieve this kind of outcome routinely — systems that solve organization problems because they are used — we believe the process of system development needs to be reengineered.

Radical Solutions.

CompuSys could have solved the configuration error problem by attacking its root causes in product complexity and incentive structures. For instance, it could have rethought its product strategy of providing customers with a virtually unlimited number of product configurations. Following the “design for manufacturability” strategies of many companies, CompuSys might have adopted a strategy of “design for error-free configuration,” involving reduced product options, standardized configurations, or “bundling” (e.g., including a cable with every port) to reduce product complexity.

Another radical solution might have involved change in organizational incentives. CompuSys could have created the motivation to prevent configuration errors by measuring, monitoring, and rewarding the sales department differently. For example, it could have evaluated sales reps and their managers on configuration quality as well as on sales volume or it could have charged the costs of “rework” against sales’s budget. Interestingly, CONFIG’s developers never provided sales with compelling information about the costs of correcting configuration errors. There was no evidence that a careful assessment of the frequency or financial impact of configuration errors — either a special one-time study or routine tracking and reporting — was ever done.

The absence of such an assessment is troubling in several respects. CONFIG’s designers were willing to spend huge sums on an expert system that would control configuration errors (if and only if the sales reps used it!), but they were apparently unwilling — or did not think — to spend smaller sums to build a low-tech monitoring and reporting system. While this low-tech solution might not have solved the configuration error problem, it might have convinced sales to use CONFIG once developers made it available.

Either solution — “design for manufacturability” or a change in the sales organization’s incentives — might have solved the configuration error problem. However, these radical solutions might have caused political and operational disruption out of proportion to the financial impact of the configuration error problem. In addition, they are solutions that information systems specialists, like CONFIG’s developers, do not normally have the political credibility and influence to champion effectively and pursue independently without top management support. Nevertheless, these solutions were much more likely to solve the configuration error problem than either the initial or subsequent iteration of CONFIG. Therefore, CompuSys management should have explicitly considered and rejected these solutions before approving and funding the CONFIG development or redeployment projects.

Implementation Solutions.

When it is politically infeasible to attack problems directly through radical solutions, an organization often addresses problems indirectly through systems like CONFIG. But when the systems themselves are not used, systems specialists often expect the users’ managers to overcome the problem through better “implementation,” for instance, by mandating system use. While we are certainly in favor of better implementation, we think that mandating system use is generally a poor solution to problems like CONFIG’s. First, we find that, when people who are not motivated to use a system are forced to do so, they frequently use it in ways that do not result in improved performance. Second, when a system has been designed so that it conflicts with the users’ motivations and incentives, managers generally will not force system use because it is not in their best interests, as we saw in the CONFIG case.

While sales managers at CompuSys might have mandated using CONFIG, they were not likely to and actually did not do so. First, as already mentioned, it was countercultural for them to force any systems or tools on the reps. If a tool was good enough, it would be used; if it wasn’t used, it was obviously faulty. Because the new, improved CONFIG wasn’t used, sales managers believed that it must be a “turkey.” Two sales managers commented:

I could go out there and hammer them into it. It’s not what I want to do. It’s going to be minimally effective. The natural tendency is for people to say, “Wait a minute, if it takes such extraordinary management emphasis, this thing must be a turkey.”

I’m not at a point where I think we should be forcing them to use it. Those sales reps are our customers, and if we’re not making them more productive, then why should I jam the use of a tool down their throats?

Second, sales managers had no incentive to demand that their subordinates use CONFIG, because they themselves were not measured on the metrics CONFIG was designed to improve. A manager remarked:

The configuration tools may be an intelligent way to make “clean orders,” but the sales organization is not measured on that. If accuracy is a problem for the company, then manufacturing should go to their counterparts in sales and say, “We think we need to have this. We think you need to measure your reps on accuracy.” But they are going to have to come prepared with the data to back that up.

In short, sales managers might have been motivated to emphasize reduced configuration errors and the use of CONFIG — even without explicit measurement and personal rewards — if someone in the organization had provided compelling data about the financial costs of errors or the possible productivity benefits from using the system. But, as we have already seen, no one did this.

Just as sales reps may not be motivated to prevent configuration errors, managers may not be motivated to prevent system nonuse. Frequently, they lack motivation because implementation strategies, such as mandating system use, are most likely to succeed when they are least needed — when systems have been designed for implementability in the first place. But systems specialists are not motivated to design for implementability because they are generally not held accountable for ensuring system use. Therefore they may ignore important opportunities to build use into information systems through better conceptual designs, as we describe below.

Systems Solutions.

If developers had built CONFIG around a different design concept, not only would sales reps have used it, but the configuration error problem would have been solved. One rep stated, “They [the developers] need to integrate CONFIG and PQS. I’m not talking about transfer from system to system — I’m talking about integration.”

As we described, sales reps used the price quotation system, PQS, because they needed to make price quotes to customers before closing a sale. If the developers had integrated CONFIG into PQS so that configurations were verified automatically as quotations were produced, with no extra work, the sales reps would have used CONFIG. The goal of producing a verified configuration would have been aligned with the goal of producing a price quotation for customers, and the goal of reducing configuration error costs aligned with the goal of making a sale.

Unfortunately, this solution — far less expensive than the CONFIG redeployment project turned out to be — was available to CONFIG’s developers all along and they deliberately rejected it. Sales reps who had been heavily involved with CONFIG’s original development recalled requesting this function as early as 1982. Minutes of the design team meetings show that users repeatedly brought up the need to integrate CONFIG and PQS. Developers argued that this would be too challenging technically and made integration a “non-goal” for CONFIG’s first release. Later, when confronted with ample evidence of CONFIG’s nonuse, they never revisited this initial design decision. Instead they poured millions of dollars into interface, platform, and implementation changes that did not address the root causes of the reps’ lack of motivation to use CONFIG.

Why were the reps’ requirements ignored? Part of the problem stems from inadequate theories of systems analysis and design. Systems specialists are trained to focus on the technical challenges of expert system engines, for example, rather than on the organizational problems of motivating users. But a deeper cause lies in the way most organizations structure and manage the business process of “organizational improvement through the use of information technology,” which supports and reinforces systems specialists’ behavior. It is this issue we turn to next.

Building Information Systems to Solve Organizational Problems

We can easily understand the problems at CompuSys as instances of “process suboptimization through subprocess optimization.” Configuration errors in the order fulfillment process occurred because CompuSys set up the sales organization to deliver customer orders with the accountability for the cost of fixing the errors passed on to manufacturing. Similarly, attempts to solve the error problem by optimizing configuration tasks with CONFIG failed, because this strategy suboptimized the larger sales process of which configuration was merely a part (see Figure 2).

The way in which systems are designed, built, and implemented in most organizations today also exhibits process suboptimization through subprocess optimization (see Figure 3). The goal of system building should be organizational improvement — solving organizational performance problems or capitalizing on business opportunities for cost reduction, gaining strategic advantage, and the like. For systems to achieve organizational improvement, several subgoals must also be met. First, the system has to be designed so that, when people use it as they are intended to, they will achieve the goal. Second, the system has to work properly and be usable. In other words, it must have adequate functionality and an acceptable platform and interface, so that people can readily employ it to accomplish a goal, if they are motivated to do so. And, third, people must actually use the system in the intended manner. Thus management has to measure, monitor, and reward their progress toward the goal.

The third step — ensuring use of the system and rewarding achievement of the goal — is absolutely essential. Unless people actually use the system to achieve the goal, the system itself is worthless, and all the resources spent in building it, getting it to work right, and making it user-friendly have been utterly wasted. But getting people to use the system can be impossible to achieve if systems are badly designed. Unfortunately, most organizations have optimized the second step — building functional and usable systems — at the expense of good system design and realized business value.

When we look at the organizational improvement process in many organizations in terms of functional accountability, we can see that system use and performance improvement is a highly unlikely outcome. In many companies, the managers of units in which the systems are used often have no direct authority over the system developers. System developers are frequently organized in specialized functional units outside the user managers’ sphere of authority, which means that the developers and the managers almost always have different objectives and measures of performance.

For instance, the IS unit in most companies is measured and rewarded for producing systems on time and on budget. Based on the implicit (and often erroneous) assumption that the user managers will take responsibility for ensuring that the systems will be used, the IS unit is usually not held accountable for delivering systems that are used. As a result, developers have little incentive to produce system design concepts with use built in. What developers think makes a system good —it works, it’s technically elegant, and it’s easy to use — is not necessarily what makes people want to use it — a good fit with their natural incentives and motivation. Even more problematic, there may not be a good fit between what people say they want and the needed organizational performance improvement. In short, while systems specialists view their role in terms of building systems that satisfy users’ requirements, they do not always take responsibility for achieving the linkage between systems and realized business value.

Conversely, the limited control that most user managers have over systems developers engenders apathy and abdication of responsibility for ensuring that systems are used and deliver business value. The managers tend to blame the system’s lack of use on the system itself, because they assume that, if the system is good enough, people will want to use it. Then, when a system, like CONFIG, appears to require “extraordinary management emphasis,” they tend to regard the system itself as “a turkey” or “an Edsel.” A CompuSys sales manager commented:

I heard the Edsel was a wonderful car, but nobody wanted it. Maybe that’s what CONFIG is. It’s a great tool. It works well and it does what it’s reported to do. However, it’s not meeting the sales reps’ needs and . . . I think it’s the wrong tool [for us].

When users and their managers think systems are turkeys, they blame the developers. But since unused systems often work well technically, developers point back at the users, saying that they built (the technically and economically feasible part of) what the users said they wanted. A classic catch-22!

Situations like this are especially likely to occur when the true client (funder and primary beneficiary) of a system is not the manager, but some third party. At CompuSys, specialists in manufacturing developed CONFIG for people in sales to reduce manufacturing’s inspection and rework costs. As in the case of CONFIG, the allocation of responsibility for organizational improvement in many companies leads to a situation in which no one — not systems specialists, clients, or user managers — is effectively managing IT’s use and business value.

In short, by optimizing system building, organizations run the risk of suboptimizing organizational improvement. This problem is thorny but by no means impossible to solve. We believe that its solution rests on two key principles: (1) the alignment of interests between system builders and those who have to implement the systems; and (2) the creation of good system design concepts.

Alignment of Interests between Developers and Implementors

We think that arguments about who alone should be responsible for ensuring system use and value — the developer or the users’ manager — are ultimately futile. The only workable answer is that both must be. Just as neither engineering nor manufacturing alone can ensure that product quality goals are met, neither systems specialists nor user managers alone can ensure organizational improvement. Consequently, solutions to problems of suboptimization in organizational improvement must target both the IS professionals who build systems and the managers who must implement them. There are two promising approaches — “concurrent system development” and new approaches to the management of systems development.

By concurrent system development, we mean something similar to concurrent engineering in the manufacturing arena. Just as new products must be designed with manufacturability in mind, information systems must be designed for implementability. Concurrent engineering requires new forms of teamwork between product and manufacturing engineers; concurrent system development requires new forms of teamwork between developers and implementors. We describe some of the specific techniques that concurrent system development teams can use in the next section.

To be successful, the concurrent system development approach must be bolstered by appropriate management structures and processes. The most straightforward, if also the most radical, way to ensure that systems are used and provide business value is to devolve total responsibility for IT investment and system success to business unit managers. One CEO recently explained to us how he had decentralized his organization into business units with profit and loss responsibility and all the resources required to support them, including system development specialists:

We don’t have systems projects any more; we just have business projects. We’re working on a lot fewer system development requests, but all the requests we fill deliver business value. Business unit managers know that it is their job to make the systems work, and the IS folks know that it is their job to support the business units.

Despite its elegant simplicity, this strategy has drawbacks. It requires the formation of business units with profit and loss responsibility. It will not work in functionally organized companies like CompuSys, where profit and loss responsibility is vested only at the very top. The reason is that, because so many important business processes cut across functional lines, giving functional unit managers responsibility for system development almost guarantees suboptimization.

Nevertheless, something very like the same result can be achieved by requiring, as a condition of funding approval, that every system development project has a business sponsor who guarantees achieving defined business results. However, this strategy will work only if the sponsor is actually evaluated and rewarded on the basis of goal achievement.

A clear threat to this strategy is the cycle time of system development. By the time the system is complete enough so that results can realistically be expected, designated sponsors have often moved on. While there is no easy answer to this problem, it is clear that most organizations should adopt development strategies that produce significant results in two years or less. Companies should carefully review and possibly terminate system development projects that drag on and on, particularly those that have lost their initial sponsors.

At the same time, the organization should evaluate and reward the systems specialist with primary responsibility for delivering the system on the basis of how successfully the system is used. Functional metrics like project schedule and development cost are clearly still important, but exclusive reliance on them leads to a lack of alignment between IS specialists and project sponsors. To create incentives for systems to be designed for implementability, the company should measure IS specialists on system use. Before a system development project is approved, the organization should require developers, in collaboration with users, to specify target levels of system penetration (percentage of all “eligible” users who adopt the system) and use (how much they use the systems and what they use them for). The system proposal should contain a sensitivity analysis — how badly the payoffs from the system will be affected if it is not used as much or as well as projected. The company should audit actual levels of use.

Funders should take an especially close look at proposals in which the decision about whether to use the system is left to the users’ discretion. As we have already said, mandating system use is rarely the answer to achieving benefits from IS. But, if the decision to use a system is left up to users who are not currently motivated to, or rewarded for, achieving a particular result, using the system is unlikely, especially if it requires much behavioral change. Projects with these characteristics are the systems equivalent of the “Hail Mary pass” in football. But, whereas the Hail Mary pass provides the possibility of success at very low cost, the poorly designed discretionary system is both risky and very expensive, and thus should not be funded.

Creating Good System Design Concepts

Traditional system building rests on two key techniques — requirements definition and systems analysis. In defining requirements, the systems specialist elicits from users a list of statements about what the proposed new system needs to do — for example, the kinds of reports it will produce. Often referred to as “laundry lists” and “wish lists,” users’ requirements afford little guidance about the relative priority of different features and what can safely be deleted when time and funds run short. In systems analysis, the systems specialist documents how the system is going to produce the requirements — for example, a step-by-step flowchart showing how the system will transform various user inputs into the needed outputs. While such documents are essential for communicating to those who will actually build a system, they do not communicate effectively to sponsors and users about how and why the business process will change when the system is introduced.

These two traditional techniques of system building should be supplemented with two additional ones —the articulation of design principles and the development of alternative design concepts. As usually defined, principles are statements of beliefs about how the organization wants to use information technology in an overall IS infrastructure.3 It is very helpful to articulate design (or redesign) principles for particular information systems and business practices as well. For example, CONFIG’s developers might have suggested that the new configuration function be designed to “interface seamlessly” with the existing PQS system, so that sales reps would not have to do duplicate data entry or awkward data transfers. And, in the area of business practices, CONFIG’s developers might have stated that sales will produce “zero defect” sales orders.

The design concept is a succinct statement that captures the new system’s importance to the business and what role it will play in the larger organization. For example, the design concept for an expert system like CONFIG might describe its purpose as “improving our ability to attract and retain customers” and explain that sales reps will use it while preparing price quotations for customers, since price quotations form the basis of sales orders.

Developing system design principles and design concepts involves skills that are different from those used in traditional systems analysis and design. Traditional system development techniques are highly analytical; they involve breaking down the “as is” business process, specifying how it works now, and looking for opportunities to employ information technology in various parts of the process. By contrast, the new techniques we propose are highly “synthetic,” in which the developer identifies the role or purpose of the information system in the larger organizational system.4 Table 1 compares systems requirements definitions to system design principles and a systems analysis to a system design concept.

By specifying the role or function of a system in its larger organizational context, the system design concept identifies several different kinds of stakeholders, including the “users” — those who must interact directly with the system in some way but who do not necessarily benefit, “beneficiaries” — those who benefit directly from the system, but do not necessarily use it, and “clients” — funders, who are usually beneficiaries but are not necessarily users or user managers.5 Although systems specialists tend to assume that users are among the system’s primary beneficiaries, hands-on users often get no direct benefit. In fact, the system often requires them to bear extra costs so that others can benefit. Not surprisingly, this is a leading reason for not using the system.6 Systems are much more likely to succeed when the hands-on users are the primary beneficiaries, and, with creative design, systems specialists can achieve this. Thus, the discipline of clearly articulating the system design concept can expose inequitable distributions of costs and benefits that threaten success and suggest alternative design concepts for a system that is likely to be used without “extraordinary management emphasis.”

A good design concept description also serves as a vehicle for effective discussions with clients and users about the business value of the proposed information system. We recommend that designers working with users generate several alternative design concepts for presentation to clients, because the design concept provides a more powerful way to communicate how the system will add value than the typical laundry list of system features. It can help prevent “scope creep” in which users add more and more costly “bells and whistles” to the system requirements. Users cannot always give the real reasons for not using the system (i.e., no rewards), so they request modifications to justify the lack of use. Some bells and whistles, while actually quite helpful, do not add enough business value to a system to justify their cost. Others may actually discourage users from making needed changes in business practices. Thus, good system design concept descriptions can help clients construct a solid business case for building the system so that it has some features but not others (see Table 2).

Why User Participation Isn’t the Whole Answer

The recommendations we have made represent radical changes in the traditional system-building process. While some readers may argue that the same objectives can be achieved through increased user participation in IS development, we do not believe that it is a total solution to the suboptimization problems we have described, for two major reasons. First, users are not professional developers, and, without professional design assistance, they tend to “pave over the cowpaths” or miss important opportunities for improvement in business processes and applications of appropriate new information technologies.7 Second, the current allocation of responsibilities gives IS specialists the incentive to put technical concerns before the users’ requirements.

Employees and their managers tend not to see entire business processes but only their own limited roles. Consequently, unless they are trained in the principles of effective business process design, their redesign ideas are likely to be limited or flawed. Similarly, users often design systems that fit the way they work today but do not solve pressing business process problems. Even strong proponents for users participating in system design increasingly warn that it can lead to a form of “incrementalism,” rather than to the radical performance improvements so many organizations need.8 Reengineering experts occasionally find, for example, that when work is radically simplified, new information systems are unnecessary, and it is sometimes possible to dispense with systems already in place.9 But clients do not always know this, and it is generally only by working with a skilled designer of organizational improvement initiatives that they are likely to find it out.

Even when users have good redesign ideas, their ability to implement changes involving information technology is dependent on IS specialists’ accurate understanding and faithful interpretation. Yet the current division of labor in system building — with specialists responsible for the technical success and cost of a project but not its business results — gives IS specialists the incentive to emphasize technical matters over users’ needs, as happened with CONFIG. The developers of CONFIG didn’t build what the users said they wanted; its intended users repeatedly made it clear that they wanted CONFIG to be integrated with PQS, but the developers rejected their request. The developers cited technical concerns, but it may be more accurate to say that they could not see the value in the users’ request because it conflicted with their own preferred design concept — of CONFIG as a stand-alone system. Because developers are rewarded for attending to technical matters, they can often get away with ignoring users’ stated design requirements by invoking a technical rationale that users don’t have the expertise to challenge. The drawback, of course, is that technical issues and improvements are rarely the root cause of, or solution to, problems of system nonuse.

Although we do not believe that greater participation by users is a total solution to the problem of unused systems, we are definitely not saying that their participation has little value. We believe that participation is necessary but not sufficient for good system design concepts, because developers’ unaided intuitions about users’ jobs and business processes are so very often wrong — as in the CONFIG case.10 However, leaving the design concept entirely up to the clients is like building a house without using an architect: a few people manage to do this and are happy with the result; most who try it aren’t. But leaving the design concept entirely up to systems specialists is just as bad. It’s like letting the architect decide what kind of house you want to live in: you’d do well to remember that she or he isn’t planning to live there. The conclusion is inescapable: users and developers must design systems together, jointly optimizing users’ knowledge of their tasks and incentives and the principles of effective business process and system design.11 One of those principles is that a good system solves the problem and is used.

Implications for CEOs and CIOs

In summary, these are our recommendations for senior managers and IS specialists. Senior managers should:

1. Align the interests of system developers and the managers who must implement information systems.
   • If possible, restructure the organization to give business unit managers responsibility for investment and design decisions involving the use of IT to ensure that clients, users’ managers, and development staff all have similar interests.
   • Otherwise, enlist a sponsor who will take responsibility for achieving defined business results from implementing the system and ensure that the sponsor has the right resources. Measure and reward both the sponsor and the developer for achieving system use and value.
   • Whenever possible, keep the system development time frame short by dividing projects into modules, each of which delivers business value. Consider terminating projects that exceed the specified time frame or lose their sponsors.
2. Initiate serious reviews of the proposed system design concept and plans for achieving system use and value.
   • Many organizations review system development projects for initial and ongoing funding approval, but these reviews typically focus only on metrics within IS functional control. Other reviews include plans for implementation and business process change.12 We recommend expanding design reviews still further in two additional ways.
   • First, senior managers should expect design reviews to cover projections of system penetration and the extent and quality of use, and commitments to obtaining this level of use, in addition to implementation plans. Statements of expected benefits (and commitment to achieving them) should be accompanied by analysis of their sensitivity to shortfalls in use levels.
   • Second, senior managers should expect design reviews for initial system funding to cover the system design concept, and they should plan to conduct another review for any significant change in scope. Whenever possible, system developers should propose several design concepts for the same situation, so that the pros and cons of the different alternatives can be actively debated. This process can help reveal conflicting interests that lead to the loss of sponsorship, nonuse, and the system’s failure to achieve business value.
   • A small, independent review team for each system proposal should be composed of a few knowledgeable, respected members of the user groups (but not those who have participated in developing the design proposal!) and a few outsiders — particularly from the human resources and accounting functions. The review team should present its report after the design team offers its proposal, with ample time for questions and discussion of alternative design principles. Perhaps this is costly, but not as costly as building a system that people refuse to use.
3. Put teeth in system investment decisions by measuring and managing system use and value.
   • Regardless of the accountability structure for systems in the organization, senior managers should initiate periodic reviews of key operational information systems. How widely are they used? How well are they used? What evidence is there that they provide a return on the very considerable effort required to keep them going? What needs to be done to improve their use and value? It is often possible to achieve very large increases in the business value of existing information systems with relatively small investments in retraining and dissemination of internal “best practices” through a systematic assessment of completed projects; few organizations make this a high priority.

Systems specialists should:

1. Accept responsibility for system use, not just systems.
   • Although systems specialists may lack incentives to focus on use, there is a sound business rationale to do so anyway. Incentives notwithstanding, it is in IS specialists’ best interests to build systems that will be implemented. Systems specialists live and die by their credibility with clients; the successful ones are perceived as contributing to improved organizational performance. Like it or not, when systems are not used, clients blame the systems. And IS specialists who acquire a reputation for delivering these “turkeys” are not respected, even when they do so “on time and on budget.”
   • Systems specialists should (politely) refuse to develop systems for which a sponsor is lacking at the outset or leaves before the project is fully deployed and used, or when a client insists on a design concept that will not be used and he or she cannot be convinced to consider a more workable alternative.
   • Life is short, and resources are scarce. Why spend time and the organization’s money on systems projects that are almost certain to fail? Systems specialists should help shape system design concepts so that the organization’s improvement goals can be achieved.
2. Focus on the system design concept in addition to user requirements and, wherever possible, propose multiple design concepts.
   • The laundry list approach to defining “user requirements” does not effectively sort out the priorities of different stakeholder groups. The design concept approach does.
   • The benefits of the design concept as a way to communicate with clients and facilitate organizational consensus are magnified when the specialist presents multiple design concepts for the same business situation. Some alternative design concepts might involve low-cost, low-technology, or nonsystems solutions, such as organizational changes. Others might vary the amount of process or behavioral change required or change the boundary between the role of the user and the role of IS.
3. Employ user-participation strategies as a way to get a good design concept, not just user “buy in.”
   • IS specialists have long recognized the value of user participation in creating commitment. But this strategy works well only when the system itself is good. And users’ views of how good a system is hinge on its design concept — its organizational purpose and how it distributes noneconomic costs and benefits among different organizational groups. User participation is a way to get the design concept right, not just to “work the process.” IS specialists’ roles in system development are twofold. First, they should add value to users’ untested statements of requirements by representing them in integrated, internally consistent packages of ideas that can be communicated, evaluated, compared, and debated in a holistic way. Second, they should create a forum in which a good decision about the system design concept is reached.

Conclusion

Systems do not improve organizational performance or create business value; users and their managers do. If the desired improvement conflicts with what people are motivated to do, a system alone will not solve the problem. There are only two alternatives: one is to change people’s incentives, in which case a system may not be needed; the other is to build a system that conforms to incentives, in which case change may not occur. The real design skill is to bring together both system use and performance improvement — by building a system that helps bring about change because people want to use it. It is both necessary and possible for systems specialists (with the aid of users) to design performance-improving systems with use built in. And when systems are built in this way, users really will come.