There is hope for executives imprisoned by their information systems. For years, an inability to change those systems quickly has thwarted promising business innovations. But several new approaches to systems development are now able to deliver business benefit fast. Not all of them are technically elegant. Not all of them will work in every situation. But, taken as a group, they make even major changes to information systems possible in weeks or months—rather than the years required by traditional efforts.

These new approaches achieve this, in part, by overturning many assumptions that underlie traditional development strategies, among them:

Old "legacy" systems must be totally replaced. In fact, legacy systems can often be supplemented or modified to provide most or all of the business value of a new system at a fraction of the time, risk, and cost.

Systems must be tailored to the unique way in which a company does business. Too often, customized systems development does not stand up to cost/benefit analysis. Especially for relatively standard processes that do not confer competitive advantage—general ledger, accounts payable, accounts receivable, and order processing, for example—the economics increasingly favor the purchase of standard software packages. Instead of customizing software to fit a business, it is usually more effective to change business processes to fit the software.

Systems are best designed in their entirety first, and then constructed. Potential users can rarely define in advance exactly what they need a system to do. Indeed, in today’s business environment, their needs are likely to change two or three times during the four- to five-year course of normal systems development. So instead of trying to plan every detail in advance, it is better to build the parts of the system that have the greatest potential to deliver business value quickly, put them into operation, and then refine and improve the system as needs become clearer.

Business value

These new approaches have already demonstrated their ability to deliver

More important than their overturning of old assumptions, however, is the fact that these new approaches have already demonstrated their ability to deliver new and improved systems more quickly, more cheaply, and more reliably than can traditional methods:

• An electronics manufacturer replaced its core product design, product installation, and aftersales service systems—approximately 80 different pieces of software, running on four different hardware platforms—with two standard software packages. From concept to rollout, this substitution took less then two years, cost a fraction of a custom-built replacement, and slashed ongoing support and maintenance costs.
• A consumer goods company developed and installed in less than eight months a new PC-based system to enable salespeople to plan sales "events" for any product in any store. Using scanner data and projections of the likely costs of each promotional event, the system also helps them analyze how much profit a proposed event will yield—both for the store and for the company.

A question of priorities

80 percent of the value of any system can be captured quickly and easily; the remaining 20 percent is often so hard to capture as to be not worth pursuing

One reason that existing systems-building methods are so slow to deliver business benefit is that they are frequently shaped by the systems developer’s priorities, not those of the business itself. In the traditional development process, developers can become isolated from business needs. As a result, they spend a great deal of time solving technical problems that bring only marginal business benefit. A good rule of thumb is that 80 percent or so of the value of any system can be captured relatively quickly and easily—and that the remaining 20 percent can often be so hard to capture as to be not worth pursuing.

The new development approaches discussed below keep efforts focused on the economic 80 percent. These approaches come in three distinct forms. Each applies to a different situation, and each puts a slightly different twist on the challenge of devoting energy only to those developments that deliver meaningful business value (see Exhibit 1). But they all do deliver value. Supplemental approaches, for example, can bring new systems on line at as little as a tenth of the time and cost needed for a more conventional approach. Even rapid custom development, the least attractive of the new approaches, can typically save half the usual time and cost—and at lower risk (see Exhibit 2).

Supplemental systems, the first option to consider when new systems capabilities are required, take existing systems—which must be in reasonable technical shape—and add on only those new functions that are required to capture business value. This approach might, for example, involve building a user-friendly front end to support a broader group of users. Or it might mean altering a system’s logic to support a completely different method of calculating results. Whatever the specific modification, the key idea is to change as little as possible of the existing system.

Standard systems—that is, off-the-shelf software—are the second possibility to consider when systems capabilities need upgrading. They come into play when existing systems are not sufficiently robust to support a supplemental approach. The essence here is to ensure that the number of changes and customizations made to a standard package is kept to a bare minimum. As new capabilities are bought, not built, this approach can deliver results quickly and inexpensively. For obvious reasons, however, it should not be applied to those few processes where a unique way of working provides a company with crucial competitive advantage.

Rapid custom development becomes relevant when neither supplemental nor standard systems can be used. The core of this approach—and the vital difference that separates it from traditional approaches—is its emphasis on not waiting for a complete plan to be finished. The elements of a system that promise greatest business benefit are built and deployed as quickly as they can be identified—and then steadily adjusted and improved to remedy inevitable shortcomings. Putting systems design in the context of the demands of real work, not the comfortable abstractions of the planning room, makes it easier to distinguish capabilities that provide genuine value from those that just sound like a good idea.

Building the new by supplementing the old

Like transplanting a high-powered new engine into the body of a classic car, supplemental systems replace a few specific parts of an existing system with something capable of higher, as well as more carefully focused, levels of performance. They are able to manage this trick because information systems are not monolithic, but can be broken down into four generic parts (see Exhibit 3):

The user interface includes the screens that a user of the system sees, as well as the commands he or she enters with mouse or keyboard. Typically, the interface accounts for 10 to 15 percent of the system’s code—that is, its programming-language text.

Error prevention ensures that the things done with the system make sense—for instance, that people do not have negative ages and that payments are not promised on February 31. It usually accounts for 30 to 40 percent of the code.

Databases and communications, which take up about 40 to 50 percent of the code, gather and store the raw information that the system is to work on. They also deliver it to where it is needed.

Core logic is the calculation or information manipulation that gives the system its "brains." It accounts for only about 5 to 10 percent of the code.

Doing more with less

Whatever old dogs can or cannot do, it is possible to teach many old systems new tricks by replacing the core logic that does their thinking

The most popular and successful uses of supplemental systems concentrate on the IT components with the smallest amount of code and the greatest potential impact on performance: namely, core logic and the user interface. Wraparound approaches to systems development are, in effect, a sort of brain transplant. Whatever old dogs can or cannot do, it is possible to teach many old systems new tricks by replacing the core logic that does their thinking.

In less than a year, a major American retailer changed the way its inventory systems restocked its stores. The original system allocated inventory to stores on the basis of averages, which aggregated all sizes and colors of a particular product and also aggregated stores by historic sales. The new system restocks each store based on the specific sales of each item in each size and color, a practice that has achieved higher sales with 40 percent lower inventories. Originally, the task of rebuilding the inventory control system from the ground up had been estimated to take four years. By replacing only the core logic with new programs running on PCs and a mini-computer, the retailer managed to get a revised system up and running in less than a quarter of the time (see Exhibit 4).

Banks provide a classic example of systems improvement by front-ending, or replacing the user interface. At many banks, existing systems perform the fundamental task of managing customer accounts quite effectively. Unfortunately, they do so in a way that makes them next to impossible for people to work with. To transfer money between one account and another may involve interactions with two or three completely different systems, each with its own arcane user interface.

A new interface can conceal all that complexity behind a user-friendly, point-and- click screen on a personal computer. The result is to make the systems truly usable and, more important, to permit the creation of new financial services that require bank staff to move quickly and easily among all of a customer’s various accounts.

Wraparound and front-end approaches avoid making changes to the largest and most complex elements of a system

The success of the wraparound and front-end approaches derives from the fact that they avoid making changes to the largest and most complex elements of a system: error prevention code, communications, and core databases. All the same, as noted above, the unchanged elements must be operationally sound even if they are mediocre in performance. Furthermore, the new wraparound and front-end systems must be designed to communicate with these existing elements smoothly and efficiently. Some translation code may be needed to enable the new parts of the system to "talk" to the old—converting data, say, from the format used by the old system to a form understood by the new additions, and back again.¹

When these requirements are met, supplemental approaches can achieve dramatic results. A major consumer goods company, for example, recently implemented a wraparound to improve the systems that forecast demand for its products. The company replaced the core logic of its existing system with calculations that used a far more sophisticated statistical algorithm. Because the new system retained all of the original user interfaces, databases, and error checks, full implementation took less than six months.

A change in attitude

Technology is not, however, the only prerequisite for achieving results from supplemental systems. They also demand a new management style or frame of mind:

Desperate situations inspire creative solutions. Ask for a prototype in four weeks

Impose stretch targets. Desperate situations inspire creative solutions. Ask for a prototype in four weeks. Demand a live pilot in three months. This will force the development team to apply the 80/20 rule and really make it work.

Take calculated risks. If it is worth building the system fast, it is also worth taking some risks to achieve that speed. Bells and whistles have no place in a supplemental system prototype. The user interface in one company’s highly successful wraparound prototype was downright user-hostile—no helpful prompts or menus, and no safeguards against typing errors. The idea is to build a prototype that works, with a bare minimum of functionality, and then add bulletproofing later to meet the needs of a broader range of users.

Remember scale-up. While pushing ahead with the prototype, developers of supplemental systems must bear in mind that their system will eventually have to cope with higher volumes and heavier use than the prototype will be subjected to. Though the development team should plan on skipping many of the traditional system development steps, they must make allowances for scale-up, or the prototype’s early promise may quickly turn to embarrassment.

Involve users as developers. The prototyping process is iterative and requires continual, seamless communication between the people building the system and those using it. Keep them all on the same team—preferably in the same work area.

Supplemental systems are not the place to scrimp on technology

Employ the best technology. Supplemental systems are not the place to scrimp on technology. More powerful workstations and faster networks can often save months of work spent trying to improve the speed and efficiency of software.

Because they focus effort so precisely on the specific new pieces of technology needed to solve the business problem at hand, supplemental systems should be at the top of the list when systems development is under consideration. But if for some reason they cannot be used, the next approach to examine is standard systems.

Economies of scale

Twenty years ago, companies wrote almost all the software that ran on their computers for themselves. With every year that goes by, however, companies buy in more software. The reasons are the same ones that first brought IBM and then Microsoft to software dominance: it is more economic to devote resources to software that will be used by hundreds or thousands of customers, than by only one or two.

Lingering concerns

One common objection when a company considers buying a standard package to automate a key business process is that the package will not capture the company’s unique way of doing business. This is almost certainly true. But the question that management needs to ask itself is whether a unique way of doing business is worth preserving. Often it is not.

Some differences do matter. A few unique business processes are what create a company’s competitive advantage, and for these few a standard package is not an attractive option. But most differences between companies in the way they do business are simply the result of historical accidents. Deciding whether to keep the differences or eliminate them should depend on whichever is cheaper—building the software to fit the process, or changing the process to fit the software. Increasingly, the most effective option is to change the process, even though this may be politically and emotionally difficult for an organization to accept.

Buying a software package off the shelf can cost as little as a fifth of the price of developing it yourself. Moreover, updates come faster: many firms revise their own applications every two years or so, while commercial vendors release new versions as often as every six months. And through serving a variety of customers, these commercial firms have usually thought longer and harder about the interfaces that connect one piece of software to another than have in-house IT departments used to doing everything their own way. When the time comes to make dramatic changes to linked systems, well thought-out interfaces can yield huge savings.

One company that is now implementing standard systems projects annual savings on its IT costs of 25 to 30 percent. It will enjoy cheaper computer hardware and operating system software. It will reduce the number of applications and application interfaces that it must maintain (see Exhibit 5). And it will scale down its commitment to developing and maintaining custom code.

Software vendors are often more reliable than insiders. To stay in business, they have to be

A second objection against standard systems is that they make a company reliant on an outside supplier. This, too, is true, and evaluating the soundness of prospective vendors is a crucial part of any project using standard systems. But this objection will lose much of its sting if managers pause to remember that any information system will leave the company dependent on someone. While psychologically it may be more difficult to trust an outside supplier than someone in your own firm, the truth is that software vendors are often more reliable. To stay in business, they have to be.

Constant vigilance

When standard systems seem to fit the bill, there is one essential rule to follow in making sure that they live up to their promise: don’t customize. Many companies start out by seeking the advantages of a standard package, but then—piece by piece, exception by exception—change it completely to fit their needs. They end up with the worst of both worlds. Not only does customization wipe out the cost savings possible with purchased systems; some of the customized code may not work with later versions of the software. This prevents companies from taking up new releases as they are made available by the vendor.

People understandably resent changing their customary work patterns to fit in with a computer

Maintaining the discipline to prevent customization requires constant vigilance. People understandably resent changing their customary work patterns to fit in with a computer. So management must help to contain their desire to recreate the system in their own image: first by assuring them that the system is designed to meet the specific business objective at hand, and second by setting very tough criteria to be satisfied by any request for change.

Anyone proposing any customization must first demonstrate that the need cannot be met by the existing package and that it is cheaper to customize the package than to perform the function manually—or to change the process to fit the system. A one-year payback of four times the cost of customization is typically required to cover the real long-term expenditure involved. More-

over, would-be customizers should be constantly reminded of the rapidly diminishing returns from pursuing customized features.

Another vital element for success in implementing standard systems is overcoming the "not invented here" syndrome. This is most effectively achieved by involving the eventual users of the system in defining the high-level requirements, choosing the vendor, and preparing for implementation. Some companies involve users further in prototyping to see how the package will cope with real-life business challenges. Not only does this secure users’ commitment to the system; it also helps at the earliest opportunity to clarify the changes that will have to be made in business processes, to identify training needs, and to highlight any shortcomings of the package.

Rapid custom development

In general terms, then, it is best to develop as little new technology as possible and, instead, either to borrow capabilities by supplementing existing systems or to buy them in the form of standard systems. Sometimes, however, there is no alternative to building new technology. One such occasion is when the process to be automated provides a company’s crucial competitive advantage. Another is when the existing basic databases neither meet the technical requirements for a supplemental approach nor provide a clean interface for a standard package. In these situations, companies should turn to rapid custom development.

In the course of a highly successful implementation of standard systems, an electronics company found it needed an order-entry module different from that offered by the package. The vendor agreed to develop the new module, but was not able to complete the software fast enough to keep its client on schedule. So vendor and client decided to cooperate on a bare-bones approach, using rapid development. Within four months, a joint team had developed a prototype that worked so well that the vendor resolved to incorporate it into its standard package—and abandon its other development efforts.

As this example illustrates, the chief difference between rapid custom development and more traditional approaches lies in the fact that the systems it creates are first built as a prototype. Then the prototype is iteratively improved. The point is to build, use, and improve a quick-and-dirty version of the system, rather than try to anticipate all requirements in the original design.

A prototype should be not a laboratory experiment, but a real system, based on real databases and used to make real business decisions

To be most useful, a prototype should be not a laboratory experiment, but a real system, based on real databases and used to make real business decisions. There are two main advantages to this approach. First, prototypes give people experience in using the system. As they gain that experience, they will probably find that many of their preconceptions about what they need the system to do are false. They will also discover new requirements. Putting people and computers together as early as possible and challenging them to solve real business problems focuses all efforts on making the system work.

Prototypes cut out much of the politics that inevitably accompany any large-scale change to business processes

Second, prototypes cut out much of the politics that inevitably accompany any large-scale change to business processes. Give people a detailed argument about why such-and-such a new approach to their job might be better, and they are likely to respond with an equally detailed argument about why it might not. But show them a working system that delivers business benefits, and their resistance to change fades. The debate over the new system can then turn to how to improve it—not whether to build it.

The subsequent systems development process takes the form of a series of iterative improvements to the prototype, first "bulletproofing" the databases and then delivering whichever business improvement promises the highest value. Ideally, the pilot should be quickly gotten up and running on just part of the business, thus enabling real-life experience to be brought to bear in refining both user interface and functionality. If live pilots are not an option, the prototype must be run as a business simulation. Even so, given the requirements for reliability and usability, it is vital to switch over to real usage as quickly as possible. Delivering key functionality quickly—and postponing refinements until later—captures the greatest business value.

Just do it

The three approaches described—supplemental systems, standard systems, and rapid custom development—provide a much-needed escape route for executives trapped by the burden of legacy systems. Existing development methods have brought cost overruns, failed systems, and creeping paralysis. By making the development of new information systems a routine part of managing corporate change, these new approaches promise to return control of corporate strategy to top managers—rather than letting it waste away in stalemate between line managers and the IS department.

That said, it must be stressed that the new approaches only enable rapid development of information systems. They do not guarantee it. Managers who postpone tough choices or who obsessively try to protect themselves against every conceivable risk—however unlikely—can quickly fritter away the speed and cost savings of these approaches. The opportunities are there. It is up to managers to grasp them.