When the technology bubble burst about two years ago, some thought it would be only a short time until technology regained its luster. Others concluded that technology had been over-hyped, and we could now go back to “business as usual.”
I believe both conclusions are wrong. Technology is still early in its impact on business, and more radical changes are coming. But the recovery will take more than simply an economic correction. There are some fundamental issues in building large-scale information systems that must be addressed as well, since for many companies the promised payoff from the implementation of large scale information systems has never been realized.
Some data from the Standish Group for the year 2000 may be surprising to those not involved in developing large information systems. About 25% of the projects from 2000 were considered failures. Another 50% of the projects overran their budget or schedule, thus eroding some of the promised payoff. Of the remaining 25%, some undetermined number failed to meet the cost savings or business transformation objectives that led to the projects in the first place. This data is hard to get since some companies simply end a large project and declare victory rather than acknowledge defeat.
Why is it that information systems projects so often fall short of their goals? After working in this field for many years, and participating in some classic failures and overruns, I have identified seven reasons why large scale information systems projects fail. I’ve gone out on the limb to identify strategies for dealing with these reasons.
Not surprisingly, few of the reasons are technical. Rather, information systems that accomplish the best objectives transform the business, changing job descriptions, approaches to work, and relationships between people. Hence they expose the kind of ethical and people challenges that often are unidentified when the projects begin. My seven are given here in no particular order.
1. Bad Ideas
Sometimes an information systems project looks like an interesting way to use technology, and fails to address any true underlying business need. Other times, technology is used to simply automate what used to be done without technology. Both are bad ideas.
This problem can come from the technologists who simply want to apply some “cool” new technology without the real understanding of the business needs. But it can also come from the business leaders who are ignorant about what the technology will enable. The worst case of this is when technology is used to simply automate an old process. Since automation adds to the cost and complexity of the business without gaining a new approach for the business, I believe that automaton almost always is a bad idea.
Projects need to be examined carefully to make sure the business will be substantially better off if the project succeeds. This must include accounting for the lifecycle costs (training, support, technology management and maintenance, later upgrades, etc.) of the technology. This filter will generally catch both kinds of bad ideas.
2. Corporate Immune Systems
Good information systems projects will change the way work is done. This can lead to a (sometimes subtle) undermining of the project by people who are affected and don’t want to change.
Immune systems in the body are good things, rejecting foreign intruders. The immune system of a business is also a good thing, enabling a measure of consistency and reliability. No one would want to drive a car where the automaker tried every new idea that came along.
Sometimes people reject a new way of doing something with good reason: they have insight, sometimes not well articulated, about potential negative consequences from the change.
On the other hand, this same immune system blocks changes that are important to the business. As with the body, special care must be taken to allow the change to be accepted. Projects that fail to account for expected resistance from people affected by the project are almost certainly doomed to failure.
Engage people who will be impacted by the project, and deal creatively with the losses or changes that will give rise to resistance.
3. Lack of Shared Ownership
Too many information systems projects are either run by the IS department without substantial business involvement, or by the business without strong leadership from IS.
IS professionals are required for such projects because of the substantial technology issues requiring their expertise. Technology issues can be extremely subtle, and it requires a level of expertise to deal with these issues.
However, large-scale information systems projects ultimately are not technology projects, but projects that bring fundamental change to the business. Unless the business leaders strongly participate in the choices and compromises required, the project will fail to meet the business needs. Too often it is the case that the business leaders have no ownership in a project until the system is built. Only then do they make it clear that the system fails to address key (unstated) requirements.
Shared ownership from the beginning, dealing with the business and technology issues, is a requirement.
4. A Poor Requirements Process
The standard systems development process calls for gathering and prioritizing requirements before considering the technology, but this is not adequate for most large-scale information systems.
Some requirements may be useful but not critical to achieving most of the benefits from the project. It is necessary to understand the technology to understand the difference between a high cost idea and a low cost idea.
Further, most large-scale information systems use “off the shelf” software (and many that don’t, should). Trying to modify this software (or get the vendor to do so) generally leads to grief for both the vendor and the solution developer. The cost to make such changes is just the tip of the iceberg. Maintaining these changes over the life of the system through various versions of the hardware and software is another major cost impact. Finally, the delay caused by this work delays the opportunity to achieve the benefits from the system.
This principle is well understood in other fields such as architecture. One of the jobs of the architect is to understand what is available in standard window sizes, doors, electrical systems, etc. so the resulting project can take advantage of the lower costs of using these standard components. It has been a much slower process for software systems designers to learn the same lesson.
Getting an 80% solution quickly is almost always superior to a longer term 100% solution. Thus knowing what is possible from the available technology must both inform and limit the requirements process.
5. Lack of Systems Thinking
A new information system may offer great benefits to a particular department or process. However, the interaction of this process or department with others can produce surprising and costly “unintended consequences.”
A major source of failure for large-scale information systems is the “collateral damage” that is identified after the system has been completed. No matter how complete, any new system will have to work with some existing systems, organizations, and functions. A new system may solve the key problems for one group, but create problems for another group, thus undermining the potential benefits that were anticipated.
Never start a project without spending time trying to think through possible unintended consequences.
6. Fundamental Complexity
Information systems are made more complex over their lifecycle by the changing underlying hardware, the changing versions of software, and the changing requirements of the business.
Unlike many other large-scale systems (buildings, airplanes and automobiles for example), information systems must be built with continuous change in mind. The computer hardware portion of the system will become obsolete in three to five years. New hardware will be two to ten times more capable with new features. The software will undergo version changes annually. When a large-scale system requires several years to build, many of the parts will be different in the final production from those anticipated at the outset. Yet the entire system must continue to operate effectively with all of these changes.
Some have tried to address the problem by refusing to upgrade computers or software during the lifecycle of the project, but this is a losing strategy. The only real way to deal with the changes is to minimize the complexity throughout the project.
Avoid unnecessary complexity in features; keep the system as simple as possible.
7. Program Management Weaknesses
Running any large-scale project is difficult. An information system generally has multiple stakeholders with conflicting demands, and no obvious way to resolve these differences.
Because a large-scale system changes the way the company does business, and cuts across multiple lines of authority, it is often extremely difficult to resolve requirements from multiple sources. Further, new capability is always coming out from technology creating the opportunity to “take advantage of this new feature.” Finally, when a project manages to open new vistas for the business, an immediate reaction can be: “I didn’t know I could do that. Now what I really want to do is this.” Thus new “requirements” for the system can be added throughout the project. Responding to all of these new requirements will mean the system could always be better, but may never be finished. No benefits from the new system are achieved until the system is operational.
Managing such a project requires authority to make hard decisions, with a relentless focus on the end objective. New ideas can be put off until another release.
Al Erisman is executive editor of Ethix, which he co-founded in 1998.
He spent 32 years at The Boeing Company, the last 11 as director of technology.
He was selected as a senior technical fellow of The Boeing Company in 1990,
and received his Ph.D. in applied mathematics from Iowa State University.