186 IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, VOL. 35, NO. 3, AUGUST 1988

Actual priorities are determined, however, on the basis of the expected return on investment, the size of the R&D budget, and the need to consider both the product quality and the innovative image of the firm. Most importantly, the competitors can be expected to react and thereby undermine our strategy. We have designed a simulation model to assess the impact of portfolio balance and competitor strategies on the firm’s win probability and expected return on R&D investment. This aggregate analysis yields priorities consistent with those of incremental project assessment, as demonstrated through an example drawn from a competition for an Air Force radar contract. The advantages of using the simulation model include a more realistic estimate of the expected rate of return, especially the effect of matching competitors’ efforts; variety of sensitivity analyses; and better understanding of technological niches and nature of competi- tion.

Further research will address the use non-linear models and more flexible rule base for portfolio assessment. Work is underway to test the models of customer preferences, technical capabilities, and aggregate demand in different situations. Various interactions among project proposals and options to utilize the projects in anticipated contracts will be studied as well. The goal is to provide a portfolio simulation tool for corporate-wide technology planning.

ACKNOWLEDGMENT

The authors thank three anonymous referees and the editor for valuable comments on an earlier version of this paper.

REFERENCES D. F. Abell and J. S . Hammond, Strategic Market Planning: Problems and Analytical Approaches. Englewood Cliffs, NJ: Prentice-Hall , 1979. N. R. Baker and J. Freeland, “Recent advances in R&D benefit measurement and project selection,” Manag. Sci., vol. 21, no. 10, pp. 1164-1175, June 1975. R. W. Blanning, P. R. Kleindorfer, and C. S. Sankar, “A theory of multistage contractual incentives with applications to design-to-cost,’’ Naval Res. Logistics Quart., vol. 29, no. 1, pp. 1-18, Mar. 1982. G. E. Fox, N. R. Baker, and J. L. Bryant, “Economic models for R and D project selection in the presence of project interactions,” Manag. Sci., vol. 30, no. 7, pp. 890-902, July 1984. G. L. Lauro and A. Vepsalainen, “Assessing technology portfolios for contract competition: An analytic hierarchy process approach,” Socio- Econ. Planning Sci., vol. 20, no. 6, pp. 407-415, 1986. T. L. Saaty, The Analytic Hierarchy Process-Planning, Priority Setting, Resource Allocation. T. L. Saaty and L. G. Vargas, TheLogic ofPriorities. Boston, MA: Kluwer-Nijhoff, 1982. B. G. Silverman, “Project appraisal methodology: A multidimensional R&D benefit/cost assessment tool,” Manag. Sci., vol. 27, no. 7, pp. 802-821, July 1981. Y. Wind and T. L. Saaty, “Marketing applications of the analytic hierarchy process,” Manag. Sci., vol. 26, no. 7, pp. 641-658, July 1980.

New York: McGraw-Hill, 1980.

Successful Initiation of Expert Systems Projects

ADEDEJI B. BADIRU

Abstract-Despite the spreading excitement about the potential appli- cations of expert systems, little or no attention has been directed at the management aspects of expert systems software development projects.

Manuscript received July 22, 1986; revised May 29, 1987. The author is with the School of Industrial Engineering University of

Oklahoma Norman, OK 73019. IEEE Log Number 8717860.

This paper suggests project management concepts and techniques that can facilitate a successful initiation of new expert systems projects. The “Triple C” principle of communication, cooperation, and coordination is emphasized. Specific recommendations to the practitioners are offered.

Keywords-project management, expert systems, Triple C principle, communication, cooperation, coordination.

I. INTRODUCTION

As expert systems begin to proliferate, we will begin to see critical systems projects with short turnaround times. More and more systems delivery failures will begin to surface. To avoid such faJures (or at least minimize their effects), sound management procedures will need to be developed and put into pracdtice. Many technical and conceptual articles are now being written about expert systems. However, very little attention has been directed to the management aspects of building the systems. Unlike conventional software where programmers may have sole responsibility for systems failures, expert systems software failures may be the joint responsibility of the domain experts, knowledge engineers, programmers, and end users. Thus, for expert systems, timely and coordinated efforts from each functional area are very critical to the success of the overall system. This paper suggests the use of the Triple C principle [ 11 for initiating and managing expert systems projects. The Triple C principle presents a structured approach to the communication, cooperation, and coordination aspects of project management functions.

The principle has been successfully implemented for various projects that the author has been involved with. It was credited with the successful management of a capacity planning project in a large maintenance facility. It has been embraced by project managers in several organizations for whom the author has consulted. The Triple C evolved from the author’s observations and experimentations with his students’ group projects in a project management course he teaches at the University of Oklahoma. The same course has been taught in industrial settings on several company plants in the Oklahoma City area. Seminars on the Triple C and project management have been conducted through the Oklahoma City Chapter of the Institute of Industrial Engineers (IIE). Such seminars have served as a forum for diverse management views that have led to further refinements of the Triple C. The Triple C principle has also been successfully implemented for expert systems class projects in an expert systems course that the author also teaches. The principle was presented and acclaimed at the 1987 IIE Spring Conference [l].

To put the application of the Triple C to expert systems projects into perspective, we briefly discuss the interesting background of expert systems. Expert systems (ES), a branch of artificial intelli- gence (AI), are integrated three-part computer programs designed to mimic the thinking process of a human expert in solving difficult decision problems. Artificial intelligence, in general, involves the invocation of machine-based knowledge to solve practical problems. Expert systems use knowledge base and logical control mechanisms to solve difficult problems that normally would require human expertise to solve. In effect, an expert system is a computerized consultant that simulates the thought process of a human expert in a given problem domain. Expert systems organize knowledge in three distinct categories of data structure, knowledge base, and inference engine. The data structure constitutes the descriptive knowledge about the particular problem to be solved. It serves as the working memory of the system and signifies the current status of the problem. The knowledge base contains the ppcedural knowledge specific to the problem area that the expert system is set up to solve. It consists of both facts and heuristics. Facts constitute information that is widely known and generally accepted. On the other hand, heuristics

0018-9391/88/08OO-0186$01 .OO 0 1988 IEEE

IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, VOL. 35, NO. 3, AUGUST 1988 187

are intuitive rules of thumb that embody an expert-level decision making in the problem domain. The inference engine is the shell that provide the environment in which data and knowledge interact to solve a given problem. It is, thus, the control mechanism, similar to a computer operating system, that organizes and implements the utilization of the contents of a knowledge base.

Because of its 3-stage structure, the development of a functional expert system requires careful coordination efforts. Normally, three distinct groups will be responsible for the three components of an expert system: software engineers develop inference engines; domain experts and knowledge engineers compile the knowledge base; end users provide problem data. Since many commercial shells are now available at affordable prices, it is advisable for companies or individuals to procure one of the commercial products rather than attempt to develop a shell in-house. A major function, then, is to select an appropriate shell for the desired application. Harmon and King [3] present useful guidelines for selecting expert systems shells. The functions of building the knowledge base and organizing a problem data are best handled in-house. Since such in-house efforts will cross several functional areas, it is important to establish sound project management practices at the outset of the expert systems endeavor.

11. MANAGEMENT BY TRIPLE c The successful implementation of an ES requires a disciplined

approach which should utilize conventional project planning and control techniques. However, many ES efforts have failed and many more are doomed to failure despite the use of established project management procedures. This is mainly because excited ES embrac- ers and patrons ignored the intricate organizational and human factors which come into play in the implementation of today’s complex systems.

Explicitly or implicitly, the success or failure of any project depends on the prevailing levels of communication, cooperation, and coordination. As an example, investigations of the space shuttle challenger accident have revealed instances of lapses in the communi- cation, cooperation, and coordination functions of the project personnel. The Triple C principle facilitates a systematic approach to the implementation of a project by emphasizing the following as distinct managerial functions:

Components of Triple C

1) communication, 2) cooperation, 3) coordination.

A . Communication

Expert systems are just emerging from research laboratories into the business world. There are still apprehensions and controversies regarding their potentials. Instituting an expert systems project will, no doubt, arouse the resistance of those who detest change (especially changes involving new and unproven technology). There is much educating to be done. Those that will be affected by the project should be informed early as to:

1 ) What is being planned. 2) When will the plan be executed. 3) How will the project be organized. 4) Who is in charge. 5) Why is the project needed. 6) What are the potential direct and indirect benefits 7) What alternatives are available. 8) What is the expected cost.

9) What personnel contribution is needed. 10) What are the possible negative impacts of the project and how

11) What penalty or cost may result from not undertaking the

12) What documented precedents are available for the project. 13) Who else already knows about the project. 14) Who will be affected by the failure of the project.

Of course, since many expert systems will be of a proprietary nature, the breadth of communication may, necessarily, have to be curtailed. Nevertheless, communication, as wide as justifiably possible, is a vital first step in establishing q p e r t systems projects. A concerted effort should be made to inform those who should know. Moreover, the communication channel must be kept open throughout the project life cycle.

In addition to in-house communication, external sources should also be consulted. Organizations who have recently implemented expert systems projects can be particularly helpful in providing valuable information. Due to the widespread excitement about expert systems, many organizations are eager to publicize their efforts (see

can they be alleviated.

project.

PI).

B. Cooperation Not only must people be informed, but their cooperation must also

be explicitly elicited. Merely signing-off on a project is not enough assurance of full cooperation. In effect, the expert systems project must be sold to the potential “investors.” The investors are those who will be called upon to invest their efforts for the cause of the project. At the present time, it is not unusual to have people who are apprehensive about getting involved in expert systems projects. There are simply not enough successful application precedents to supply a motivating force. The personnel must, thus, be convinced of the merits of the project and the criticality of their contribution to the project. Domain experts are particularly apt to hold back their cooperation. There may be the fear that expert systems are being designed to replace human experts. A soothing and convincing case will have to be presented for the project.

One of the very first tasks involves an evaluation of what resources are needed for the expert systems project. Cooperation should be sought from the appropriate quarters with respect to manpower, machinery, and time requirements. The quantity as well as the level of capability for each resource type should be clearly defined with documented justifications.

I . Manpower Requirement: Manpower needs are usually difficult to quantify due to the variabilities in application objectives, personnel competence, and natural and technological constraints. Requests for manpower resources should be realistically mapped to the practicality of the project situation. Only then can there be the possibility of effective cooperation. The question of personnel training should also be critically analyzed. Expert systems are still at the stage where there is a limited supply of skilled developers. Thus, organizing a competent project group may not be trivial. The human efforts required for an expert systems software project may be categorized in the three separate roles of

1) domain expert, 2) knowledge engineer, 3) programmer.

The domain expert is the one who has the expertise for the domain area under consideration. It is his (or her) knowledge that an expert system is trying to capture in the form of a knowledge base. It is important that his complete cooperation be obtained. A lack of

v.

188 IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, VOL. 35, NO. 3, AUGUST 1988

cooperation from the domain expert can result in a missing link in the knowledge base.

The knowledge engineer is the one responsible for debriefing the domain expert. His (or her) central functions are knowledge acquisition and knowledge representation. Knowledge acquisition is the process of eliciting problem-solving procedures or knowledge from the domain expert. Knowledge representation is the process of organizing, verifying, and coding the acquired knowledge into a knowledge base. In order to build a reliable knowledge base, cooperation must exist between the domain expert and the knowledge engineer.

The function of the programmer can usually be combined with that of the knowledge engineer. In fact, it is recommended that such a centralized function be practiced whenever the project environment permits. This will help avoid another potential source of cooperation breakdown. The programmer is responsible for the development of the actual computer program codes under the direction of the knowledge engineer. Without cooperation, such joint implementation routine cannot be effective.

2. Machine Requirement: Based on the desired applications, equipment needs for expert systems vary widely. A need is rapidly developing for microcomputer-based expert systems [6]. These are essential for real-time decision applications. Until efficient program- ming techniques coupled with powerful small computer systems become widespread, most large expert systems will still be destined for the larger systems. A careful identification of the needed tools [7] will facilitate the cooperation needed (from top management) for its procurement. Even if the desired computer is already available “in- house,” cooperation must be sought for an unobstructed access. Computer systems suitable for extensive expert systems work certainly don’t come cheap, at least not right now. Computer systems are now being developed specifically for artificial intelligence applications. Some of these, for example, LISP machines, are still beyond the budget of upstart expert systems projects. Cooperation between two or more establishments to jointly share the cost and usage of hardware is a realistic alternative at the present time.

3. Time Requirement: Due to the lack of precedents for many expert systems endeavors, it is difficult to reliably estimate the time requirement. When seeking the cooperation of those to be involved in an expert systems project, it will be prudent to propose conservative estimates. The dynamism of a knowledge base makes the estimation even more difficult. Good expert systems should be growth-oriented and adaptable to new knowledge. Consequently, setting a precarious terminal date for the system completion may provide the grounds for criticism should the deadline not be met. Time allowances should be made for system updating. A safe approach is to present time requirements in terms of conservative milestones. This will assure a continuous flow of cooperation (and less criticism) from all quarters over the project life cycle.

C. Coordination Having successfully initiated the communication and cooperation

functions, the efforts of the project team must now be coordinated. The development of a “responsibility chart” (see [4]) can be very helpful at this state. A responsibility chart is essentially a matrix consisting of columns of individual or functional departments and rows of required actions. Cells within the matrix are filled with relationship codes that indicate who is responsible for what. The responsibility chart helps to avoid overlooking critical communica- tion requirements as well as obligations. Questions such as:

1) Who is to do what? 2) Who is responsible for which results? 3) What personnel interfaces are involved?

are easily resolved. Wi’h respect to coordinating the overall efforts, the guidelines presente In the next section may be employed. Table I presents the guidelines in the form of a responsibility chart. Fig. 1 illustrates the functional interfaces involved in an expert system. People from diverse functional areas and background are expected to interact to form the basic organizational structure of an expert systems environment. Domain experts work with knowledge engi- neers to develop the knowledge base in accordance with the design structure of the inference engine, which is constructed by the systems or software engineers. The user interface must provide an unamFigu- ous means for the end user to input problem data in a format that conforms to the requirements of the working memory and the contents of the knowledge base. Thus, there must exist a complete compatibility between the inputs and outputs of the various organiza- tional entities. The achievement of that compatibility rests on effective communication, cooperation, and coordination. Several case studies presented during the second T1 Satellite Symposium on Artificial Intelligence (see [SI) exemplify real expert systems project situations where the Triple C principle could have been implemented to alleviate project difficulties. To further enhance ES managerial efforts, the next two sections of this paper present specific project guidelines and recommendations for getting started.

111. PROJECT GUIDELINES

In this section, we present ten major items that constitute the life cycle of a typical ES project (see [2]). Practitioners may follow the guidelines in the order and context presented or modify them to suit their specific needs.

1. Definition of Problem Area. i) Define problem domain using keywords that signify the

importance of the problem to the overall organization. ii) Locate domain expert willing to contribute expertise to the

knowledge base. iii) Prepare and announce the development plan.

2. Personnel Assignment.

announced. i) The project group and the respective tasks should be

ii) A qualified project manager should be appointed. iii) A solid line of command should be established and

enforced. 3. Project Initiation.

i) Arrange organizational meeting. ii) Discuss general approach to the problem.

iii) Prepare specific development plan. iv) Arrange for the installation of needed hardware and tools.

i) Develop a prototype system. ii) Test an initial implementation.

iii) Learn more about problem area from test results.

4. System Prototype.

5 . Full System Development. i) Expand the prototype knowledge base.

ii) Evaluate the user interface structure. iii) Incorporate user training facilities and documentation.

6. System Verification. i) Get experts and potential users involved.

ii) Ensure that the system performs as designed. iii) Debug the system as needed.

7 . System Validation. ” i) Ensure that the system yields expected outputs.

ii) Validation can take the form of

cess in so many trials). a) evaluating performance level (e.g. percentage of suc-

b) measuring level of deviation from expected outputs.

IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, VOL. 35, NO. 3, AUGUST 1988 189

TABLE I RESPONSIBILITY CHART FOR COORDINATING EXPERT SYSTEM PROJECT

Code:

R = Responsible

A = Approve

C = Consult

I = Inform

S = Support

Actions

1. Problem Definition

2. Personnel Assignment

3. Project Initiation

4. System Prototype

5. Full System

6. System Verification

7. System Validation

0 . System Integration

9. System Maintenance

10. Documentation

-

d

a' :: C

n -

C

C

C

R

R

R

R

C -

Individuals Responsible -

L a'

2 a'

P z 2 -

R

R

R

R

R

R

C -

-

L

e e E 0

a -

R

R

R

R

R

R

C -

-

I.

: 9 d 0 a' .- 6 -

C

R

I

I

C

R

R

C

C -

-

B bB

2 4

9 k - R

R

A

S

S

C

C

A

A

A -

ENGINE

T +I INTERFACE

Fig. 1. General structure of an expert system.

c) measuring the effectiveness of the system output in solving the problem under consideration.

8. System Integration. i) Implement the full system as planned.

ii) Ensure the system can coexist with systems already in

iii) Arrange for technology transfer to other projects. operation.

9. System Maintenance. i) Arrange for continuing maintenance of the system.

ii) Update knowledge base as new pieces of information

iii) Retain responsibility for system performance or delegate become available.

to a well-trained and authorized personnel.

10. Documentation. i) Prepare full documentation of system.

ii) Prepare user's guide. iii) Appoint a user consultant.

It is conceivable that the life cycle of the projects in specific situations or companies may differ from the one presented above. Nevertheless, a practitioner can utilize the guidelines presented as a foundation for developing custom managerial procedures for expert systems projects.

3

Iv . RECOMMENDATIONS FOR GETTING STARTED

When evaluating a problem area for the application of expert systems, the following factors and questions should be kept in mind.

A . Problem Selection Problems to be selected for ES projects should be evaluated on the

basis of both their inherent structures and organizational interests. Considerations should, at least, include the following.

1 . Ease of Data Collection: How easy will it be to collect the relevant data for the problem?

2. Frequency of Problem Occurrence: Does the problem occur frequently enough to warrant the development of an expert system? If not, conventional software may be more appropriate.

3. Representation of Data: Can the pertinent knowledge be organized as a knowledge base? Are there clear-cut relationships or heuristics that can be modeled in terms of an IF-THEN statement?

4. Yalue of Problem Domain: Is the problem significant enough that it deserves the necessary commitment?

5. Cost Justification: Is the development of an expert system for the problem cost justifiable? Will the expected returns outweigh the investments?

6. Availability of Human Experts: Is there an access to willing experts to provide inputs that will form the knowledge base?

7. Resource Availability: Are the needed resources (computers, programmers, software, etc.) available? What will it cost to upgrade the existing resource to the adequate level required for the project?

B. System Development Procedure

summarized as follows. The basic procedure for a successful ES development cycle may be

1) Start with a modest goal. An overambitious project can only lead to unfulfilled expectations. Starting out simple will ensure the success that will be needed as a confidence-booster for subsequent projects. It should be noted that a functionally simple system can easily be upgraded as needed at any time.

2) Procure needed resources and make them available to the personnel.

3) Arrange a training program for both the developing personnel and the intended user personnel. Inform all those that need to know of the project and its merits.

4) Be prepared for failure on the first expert systems project. Avoid destructive criticism of the project group.

C. Barriers and Their Remedies The most common barriers to ES project initiation and implemen-

tation, as found in practice [ 5 ] , are presented here. Recommendations are offered for alleviating the barriers. The barriers, both genuine and perceived, are discussed bebw.

1. Lack of Resources: A common obstacle to the initiation of artificial intelligence project is the lack of adequate resources. This is mainly in terms of computer systems, software, and competent personnel. Fortunately, with the proliferation of low-cost powerful computers, more and more organizations are now able to initiate their

190 IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, VOL. 35, NO. 3, AUGUST 1988

own programs. Inference engines (expert systems tools) that used to cost thousands of dollars can now be procured for a few thousands. As more programming hobbyists enter the race, we are beginning to see some inference engines come into the public domain as shareware.

2. Apathy: Apathetic attitudes are another reason some companies have not yet entered the expert systems race. It should be pointed out that organizations that wait too long are going to find themselves left behind and playing catch-up.

3. Zgnorance: Expert systems are just emerging from academic and research instituions. It will be some time before all the ramifications are fully comprehended. As a result, ignorance of the technology’s capabilities is one of the major impediments to its speedy adoption. However, many workshops, seminars, and short courses are now being organized all across the nation by various academic institutions and professional organizations. These will, no doubt, help to raise the level of awareness for the technology.

4. High Cost Versus Low Return: Because of the scarcity of demonstrated results, it is sometimes difficult to justify the initial investment in terms of expected returns. As more commercial expert systems packages come into the market, we should begin to see more successful precedents upon which aspiring organizations can draw. The returns in the early years will, admittedly, be modest. But the payback should pick up as the technology gains wide acceptance. Meanwhile, the required initial investment will continue a downward trend.

5 . Loss of Human Jobs: New technologies have often been accused (sometimes justifiably so) of causing the loss of human jobs. But contrary to early 1970’s expectations that computers will cost thousands of jobs, computers are actually helping to create new jobs and ensuring that thousands more are maintained. The key to avoiding job loss lies in retraining and realignment of efforts. Expert systems should not be developed with the view of dispensing of human expertise. Rather, they should be developed to supplement and complement the functions of human experts.

V. SUMMARY

A practical guide to initiating expert systems software development projects has been presented in this paper. The Triple C principle is introduced to emphasize the importance of communication, coopera- tion, and coordination efforts as distinct management endeavors. With proper communications, all those that may be affected by the project can be informed as to what is being planned and what roles they are expected to play. Cooperation, as suggested in this paper, involves explicit elicitation of the agreement of those to be involved in the projects. The traditional project sign-off requirement for initiating projects is not necessarily adequate for expert systems projects because of the subtle reservations many people still have about the new and “unproven” technology of the systems. The standard responsibility chart is presented as a mechanism for coordinating the efforts of the project personnel. The roles of domain experts, knowledge engineers, and programmers are discussed in the context of initiating and managing an expert systems projects. Specific recommendations to the practitioners for getting started are presented. The guidelines can be easily adapted for a customized procedure for any specific project situation.

REFERENCES

[ I ] A. B. Badiru, “Communication, cooperation, and coordination: The Triple C of project management,” in Proc. 1987 IIE Spring Conf. (Washington, DC), May 1987, pp. 401-404.

A. B. Badiru, “Expert systems and industrial engineers: A practical guide to a successful partnership,” in Proc. 1987 IIE Spring Con$ (Washington, DC), May 1987, pp. 433-437. P. Harmon, and D. King. Expert Systems: Artificial Intelligence in Business. New York: Wiley, 1985. H. Kerzner, Project Management: A Systems Approach to Plan- ning, Scheduling, and Controlling, 2 ed. New York: Van Nostrand, 1984. Texas Instruments, “Knowledge-based systems: A step-by-step guide to getting started,” in Proc. Second Artificial Intelligence Satellite Symp. (Dallas, TX), 1986. R. Webster, “Expert systems on microcomputers,” Computr Elec- tron., vol. 23, no. 3, pp. 69-73, 94-104, 1985. S. Weiss, and C. A. Kulikowski, A Practical Guide to Designing Expert Systems. Totowa, NJ: Rowmah & Allanheld, 1984.

Supplier/User Interfacing in the Development and Adoption of New Hardware/Software Systems: A

Framework for Research

ROGER A. MORE

Abstract-The successful development of innovative new hardware/ software systems is critical to the viability of many computer systems suppliers. Recent evidence provides numerous examples of such supplier companies having difficulty in profitably introducing these systems into potential customer organizations. Adoption has frequently been slower than expected, has provided lower profit margins, has required much greater supplier resources, and in some cases has resulted in withdrawal from the market with severe financial losses. These problems have often been attributed to supplier problems in managing the system development process. In many cases, however, a major problem for supplier compan- ies has been effectively interfacing with customer organizations as they decide whether to adopt a system or to reject it. This interfacing and its relationship to the development process is very complex and not well understood by many managers. As a result, many harriers to the adoption of a system are unanticipated and unmanaged. In many of these situations, more effective interfacing of the supplier organization with the user organization could have had a major impact on the success of the adoption.

A conceptual framework has been developed which identifies and maps different patterns of supplier/user interfacing in the development and adoption of new industrial products. This paper applies this framework to two empirical examples of CAL adoptions explored in a case-based field study. The supplier/user patterns suggest that there are many different potential relationships that can evolve, and that the management of these relationships can profoundly affect the adoption rates for these types of new technologies. The patterns identified in the examples provide the basis to identify a series of important research questions in this management area.

INTRODUCTION

The successful development of innovative new hardwarekoftware systems is critical to the viability of many computer systems suppliers. Recent evidence provides numerous examples of such supplier companies having difficulty in profitably introducing these systems into potential customer organizations. Adoption has fre- quently been slower than expected, has provided lower profit

” Manuscript received August 4, 1986; revised September 21, 1987. The author is with The School of Business Administration, The University

IEEE Log Number 8719114. of Western Ontario, London, Ontario, Canada N6A 3K7.

0018-9391/88/0800-0190$01.00 0 1988 IEEE