The role of prototyping in executive decision systems

Information & Management 21 (1991) 257-267 North-Holland

257

Research

The role of prototyping in executive decision systems Introduction

Tor Guimaraes Tennessee Technological University, College of Business Administratlon, CookeviNe, TN38.505, USA

Jayant

V. Saraph

St. Cloud State University, College of Business Administration, St. Cloud, MN 56301, USA

Prototyping has been widely acclaimed as an effective approach to requirements definition and systems development. It is often claimed to be particularly useful in the development of systems to support executive decision making, which by definition deal with unstructured business problems. Data from 109 top executives and 34 MIS managers from 40 organizations are used to identify executives’ problems with information systems and the alternative and complimentary solutions to these problems. Prototyping is rated quite highly by MIS managers as a solution to many executive problems. The benefits of prototyping suggested in the literature are clearly borne out by the study. Keywords: Prototyping, Decision support systems, DSS, DSS problems, Information systems management, Executive information systems

Tor Guimaraes holds the J.E. Owen Choir of Excellence in Information Systems at Tennessee Technological University. Previously he was MIS Professor and Chairman of the Business Computer Information Systems (BCIS) Department at St. Cloud State University. In addition to his Ph.D. in MIS from the University of Minnesota, he has an M.B.A. from the California State University, Los Angeles. Before moving to St. Cloud State, he was an Assistant Professor of IS and Director of the MIS Certificate Program at Case-Western Reserve University. He has spoken at numerous meetings sponsored by professional organizations including ACM, IEEE, ASM, DPMA, INFOMART, and Sales and Marketing Executives. He has consulted on several IS topics with many leading organizations including TRW, American Greetings, AT&T, IBM and the Department of Defense. He has published over forty articles in leading journals such as Communications of the ACM, MIS Quarterly, OMEGA, Computers and Operations Research. Information and Management, and Database. 0378-7206/91/$03.50

As computer technology is increasingly being used to support executive decision making, the traditional methods of developing transaction processing systems begin to falter due to their inability to handle unstructured and multifaceted end-user requirements. In such cases, prototyping has been recommended as an alternative system development approach. While prototyping is generally beneficial in most system development efforts (i.e., for transaction processing applications), it is likely to be more useful in the development of decision support applications which deal with less structured business problems. Prototyping has been suggested as a vehicle to address poorly defined system requirements [12]. In applications used to support executive decision making, end-users are often unable to define system requirements because: (1) the business problem may be too complex and poorly understood by the end-users, (2) the end-users may understand the problem, but be unable to communicate it properly to system developers, (3) the problem may change while the system is being developed, (4) the problem may be unstructured, defying clear specification until a prototype is implemented and exercised by the end-users (see Jayant V. Saraph is a recent Ph.D. graduate from the University of Minnesota in Operations Management. He received a B.S. in mechanical engineering from the Indian Institute of Technology, Bombay, India, and an MBA from the University of Minnesota. Dr. Saraph’s current research interests are in quality management, productivity, service operations, JIT, and manufacturing strategy. He has published in Decision Sciences, Management Science and Production and Inventory Management Journal.

0 1991 - Elsevier Science Publishers B.V. All rights reserved

258

Information

Research

[33] for a discussion of unstructured problems), and (5) the system may be required to serve many end-users with different needs and interests, making system requirements unclear and volatile [22,36,39]. Prototyping is recommended for two important reasons. First, prototyping requires a very high degree of interaction between end-users and the system developers, thus guaranteeing a high degree of user participation; this has been found to increase the usage of the decision support system [l]. Second, interaction also improves the user’s ability to provide system specifications more clearly in an evolutionary fashion; this is critical for successful system development and implementation [2,28,32]. With increasing corporate interest and activity in executive decision support applications, and lately in group decision applications [e.g. 8,9,11,18,20,26,37,40], prototyping is destined to play an important role in systems development. Some authors [e.g. 5,10,13,19,23,27] even suggest that prototyping is a “revolutionary” method for developing systems and claim that it will replace the “traditional” system development life cycle (TSDLC) [4,29]. However, there is evidence that prototyping methodologies will become an integral part of it [15,17]. In other words, the TSDLC will be modified to include a wide variety

Table 1 Prototyping

Benefits

& Management

of prototyping approaches. Some authors see it as an overlay to the system requirements definition phase of the TSDLC [6,14]. Others suggest that prototyping can supplement the TSDLC and be used throughout its phases [24,25,34]. The literature cites a few limitations such as the need for special prototyping languages, for training of the MIS staff in its methodologies, and possibility of its needing more computer resources [7]. On the other hand, the use of prototyping is claimed to offer benefits that can be classified into three major groups: (1) end-user benefits (EUB), (2) technical benefits (TB), and (3) managerial benefits (MB) detailed in Table 1. Despite the importance of prototyping, the literature fails to corroborate many of these benefits. The objective of this study is to investigate benefits and applicability of prototyping in comparison with other approaches. To keep the task manageable, the technical benefits and the possible limitations of prototyping have not been addressed here. Research Questions. The specific questions to be addressed are: ~ How useful is prototyping in addressing executives’ problems with information systems (IS)? How does it compare with other -methods of solving the same problems?

Cited in the Literature

End-User Benefits (EUB) (1) allows end-users to learn about the business problem and change their minds about the system requirements [1,2.4,7.27.28,32]. between end users and system developers, thus producing more complete (2) improves communication and accurate system requirements specifications [1,2,27,28,32], and (3) improves user participation and end-user/IS relations in general [2.27]. Technrcal Benefits (TB) help system developers (analysts, designers and programmers), technical support, data resource management. and maintenance personnel by: (1) validating user requirements before continuing systems development [2,4,7,28.32]. (2) identifying optimum structure for metadata [4], (3) integrating and validating metadata from different sources to enable bottom-up logical and physical integration of shared data [4]. (4) validating database domains [4], and (5) testing or validating alternative system designs to improve system/machine performance I4.19.281. Manogeriul Benefits (MB) help in project management and system implementation (1) increasing user acceptance of the system [4], (2) shortening the system development cycle by eliminating design errors 1281. (3) providing the basis for improved cost/benefit analysis [2,25], and (4) improving the quality of the system [2.25].

by:

Information

T Guimaraes, J. K Saroph / Prototyping

& Management

_ Are the suggested benefits of prototyping borne out in practice? _ What are the managerial implications of the use of a prototyping approach? When should it be used? When is it not applicable?

259

Phase I: Definition of executives’ problems A group of 38 (non-MIS) business executives split about two to one between middle (below VP) and top managers (VP or higher) were asked to identify and discuss possible problems they face while using or trying to use computers to assist in executive decision making. This was a convenience sample of managers attending a seminar on top management perspectives on computing. As a re-

sult of the input from the managers, the moderator of the seminar, (one of the authors) developed a list of nineteen distinct problems. The objective was to include all types of problems related to executive use of IS. Their classification and analysis is shown in Table 2. Executives have reported problems due to (a) system performance, (b) system development, and (c) executive lack of knowledge about IS technology. Performance problems are due to lack of timeliness, cost-effectiveness, quality, flexibility, reliability, and control of the use of computers. System development problems are due to executives inability to define and/or communicate their business problem to system developers. The last four problems are due to lack of knowledge regarding computer data sources, systems, or software. This list is representative of the problems executives generally encounter while using (IS) to support decision making for several reasons:

Table 2 Executives’

Making

Methodology

The phases:

Problem

research

Problems

methodology

in Applying

Type

1, Performance (a) Lack of timeliness

(b) Lack of cost effectiveness (c) Lack of quality (d) Lack of flexibility (e) Lack of reliability (f) Fear of lack of control 2. Problems in systems development for executive decision making (a) Problem definition

consisted

Information

of three

Systems

For Decision

(n = 38)

Problem Number

Problems

1. 2. 3. 4. 5. 6. I. 8. 9. 10.

Long lead times to get requested information Long lead times to have technical problems solved Using the computer is too time consuming Even “friendly” computer languages take too long to learn Computer related trouble shooting is difficult and frustrating With hindsight, the system is not cost/beneficial Poor quality of available reports Inflexible systems (difficult to change) Unreliable systems (poor response time or downtime) Losing touch with the data and/or model

11. 12.

Inability to clearly define information requirements Inability to communicate problem specifications to people trying to define information requirements and/or construct models If computers are likely to be useful, not knowing what is the best alternative to use Necessary data not available Systems development requires too much time and energy up front with no results for at least some time Not knowing when computer would be useful Not knowing how to use different software packages or new programs Not knowing how to use specific software packages and programs Lack of information about relevant data sources inside and outside the organization

(b) System design

13.

(c) System development

14. 15.

3. Problems due to lack of knowledge on executives’ part

16. 17. 18. 19.

Cited

Research

260

Information & Management

1. The relatively large number (147) of business executives participating in the development and refinement of the list. 2. The diversity of the functional areas of the participating

executives

involves

different

sizes

of firms and industry types. 3. The process used to construct the list facilitated the inclusion of as many items as possible. The process was highly interactive. 4. The original list has been validated by a separate group of business executives in Phase 3.

Phase 2: Definition

of solutions

The list of 19 executive

A-Company

from Phase

merate their possible solutions. A discussion with the MIS managers

was used

that they all understood each problem way. For each problem, three to six

solutions were proposed. The solutions groups were essentially the same.

Characteristics

Gross Revenues

Revenue

(n = 40)

(In $ millions) Number of Compcmies 4 10 9 12 5 -

40-199 200-399 400-699 700-999 Over 999

40 B-Company

IS problems

1 was presented to two different groups of MIS managers attending another seminar on user computing management. A total of 41 MIS managers were asked to examine each problem and enu-

to ensure the same

Table 3 Sample Company

Breakdown

by Industry

Indu.stry

Number of Compames 16 11 3 4 2 2 1 1 -

Types Manufacturing Multi-industry Insurance Banking Transportation Utilities Thrift Chemical

of the two

40 C-MIS

Department

Budget (in $ millions)

Phase 3: Data collection Two questionnaires were constructed, top business managers, and the other

one for for MIS

managers. The first consisted of the list of 19 problems with each followed by two Likert scales to rate (1) how often the executive encountered the problem (1 = never, 2 = seldom, 3 = sometimes, 4 = often, 5 = always), and (2) the importance of the problem (1 = extremely unimportant, to 7 = extremely important). The top managers were invited to modify or add to the list of problems, however, no additional problems were added by them. The questionnaire for the MIS managers consisted

of the same list of problems

plus the sug-

gested solutions of Phase 2. Enough blank spaces were available under each problem for managers to propose additional solutions. For each, there was a Likert scale to assess the effectiveness of each solution (1 = slightly, 2 = quite, 3 = very, and 4 = extremely effective). Data were collected from a convenience sample of 40 organizations: the marketing managers who attended a seminar on the use of computers in sales and marketing conducted by one of the authors were the entry points into the organizations. Selected company characteristics are shown

Budget

Number of Companies 1 9 13 9 8 -

1 1-2.9 3-4.9 5-10 Over 10

40

in Table 3. The sample is obviously dominated by medium and large organizations. The marketing managers were asked to invite top business

managers

(non-MIS)

and their

MIS

manager to participate. A total of 109 top business managers completed their questionnaire and 34 MIS managers completed the MIS manager’s questionnaire (6 MIS managers did not respond or responded late). Eighteen companies had two top business manager respondents, 15 companies had three respondents, and 7 companies had four respondents.

Problem

Classification

by Severity

The averages of the top business manager ratings (n = 109) on the frequency and importance of

of Prototyping

ratings

19

Executives Lock of Knowledge Lack of information about relevant data sources inside and outside the organization

* = Effectiveness

15

1

of between

14

12

11

10

I 8 9 3.4 3.6

2.0 and 3.0. Effectiveness

3.8

3.7

3.2

3.8 3.1

ratings

of < 2.0 suppressed.

3.7

*

3.2

*

* 3.4

3.2

3.7 3.5

Testing Through Report Stoppage

IS Problems

Technical Support Function

3.1

*

Help Desk

5

3.6

Coaching/ Training

3.6

3.3

Application Development center

Severe” executive

3.3

3.6

Other Solutions 4 GL Personal Report ComputGenering ators

Severe” and “Medium

*

3.3

Prototyping

“Most

2

1

Problem Number

and Other Tools to Address

System Development Inability to clearly define information requirements Inability to communicate problem specifications to system developers Necessary data not available System development requires too much time

Lack of Performance Long lead times to get requested information Long lead times to have technical problems solved Computer related trouble shooting is difficult and frustrating Poor quality of available reports Inflexible systems Unreliable systems Losing touch with data and/or the model

“Most Severe” and “Medium Severe” Problems

Table 4 Effectiveness

3.5

*

3.1

3.1

3.2

Systems Analyst, User Liaison

3.6

Tune Up Maintenante

3.4

Quality Assurante

3.4

*

Data Administration

Systems Maintenante Function

262

Research

Information

the problem are shown in Appendix A. In general, it suggests that performance problems and systems development

are more severe (im-

timely systems development. The average effectiveness rating for the prototyping solution ranges from very effective to extremely effective (2.9 to

due to lack of knowledge. problems are: (#l) long

3.8). On the other hand, Table 4 also shows that prototyping is unable to address many important

problems

portant) than problems The “most severe”

lead times of requested information, (#2) long lead times to have technical problems solved, (# 5) computer related frustrating, (#7),

trouble shooting is difficult and poor quality of available re-

ports, (# 8) inflexible systems, (# 9) unreliable systems, (# 12) inability to communicate problem specifications to system developers, (# 14) necessary data not available, (# 19) lack of information about relevant data sources. The problems considered as “medium severe” are: (#lo) losing touch with the data or model, (# 11) inability to clearly define information requirements, and (# 15) systems development requires too much time. The “least severe” problems are: the computer is too time consuming,

(# 3) using (#4) even

“friendly”

too long

computer

languages

take

to

learn, (#6) with hindsight, the system is not cost/ beneficial, (# 13) not knowing the best computing alternative, (# 16) not knowing when a computer would be useful, (# 17) not knowing what different software packages or new programs can be used, (#18) not knowing how to use specific software packages and programs. This suggests that some of the problems dealing with the executives’ lack of knowledge are not worthy of consideration, since they rank low on problem and importance.

frequency

Appendix B shows the average effectiveness rating by the MIS managers (n = 34) for each solution. Table 4 represents a summary of Appendix B for severe problems. In most cases, prototyping represents one of many solutions to a problem.

The alternative

& Management

solutions

are not neces-

sarily mutually exclusive and may be complementary. The exact relationships have been discussed in the cited literature and are beyond the scope of this paper. A straightforward conclusion is that prototyping is a very effective tool in (# 1) reducing lead times for requested information, (# 7) improving the quality of reports generated, (#8) developing systems that can be easily changed, (#ll) defining information requirements, (# 12) providing better problem specification, (# 13) developing the possible computer solution alternatives, and (# 15)

executive

Benefits

problems

(#2,

5, 9, 10, 14 and 19).

of Prototyping

It is clear that our results support the end-user benefits claimed in the literature and listed in Table 1. Table 4 suggests (problems 8, 11, and 12) that prototyping helps to define better systems specifications, and improve user/developer communication and system flexibility (adaptability changes). As a result, prototyping is thought reduce systems development time, improve tems quality, and increase user satisfaction the system. As mentioned earlier, this research ned to verify most of the technical prototyping. However, typing will indirectly

to to

syswith

is not desigbenefits of

Table 4 shows that protoenhance the validation of

user requirements, by addressing the executives’ inability to define information requirements (# 11) and communicate requirements to system developers (#12). The managerial benefits of prototyping claimed in the literature relate to the impact of prototyping on systems development management and system implementation. Table 4 indicates that prototyping improves (by addressing problems 1, 6, 7. 8, 12. 13, and 15) user acceptance through better user/ developer communication and more accurate system specifications. Further, following the same rationale, the prototyping approach is likely to improve the system developers’ ability to respond to changes in user requirements. As a result, from improved

system definition,

is thought to provide higher quality and greater systems cost/effectiveness run.

prototyping information in the long

Other Major Conclusions 1. It is clear that the areas that most benefit from prototyping are problem definition, systems development, and implementation. IS department performance in these areas is most visible to the end-user community and this has great

In/ormation & Management

implications for the department and the company. Improvements provided by prototyping are extremely important to all concerned. Prototyping is not a “cure all”. While prototyping pays off handsomely in the areas of system performance, enhancement and system development management, it is not useful for many other problem areas. For example, it cannot help much in solving well defined but complex technical hardware/ software problems; or when requisite data are not available or are inaccurate. Such problems require other solutions, such as technical support, software quality assurance, user training, and effective data administration. The practices most complementary to the prototyping approach are (1) the use of systems analysts or user liaison to improve communication between the users and developers to provide better system specifications and to improve the quality of the reports, (2) the use of fourth generation languages and report generators to allow flexible systems, (3) the use of personal computing to allow users to develop their own applications quickly, and (4) the use of help desks and user coaching to alleviate the problems of doubting when computers would be useful, answering what alternative to use, and what software package is best, etc. However, in most cases, prototyping was judged equal or superior to these complementary practices in terms of individual effectiveness. The role of prototyping in a given organization is dependent on the specific problems encountered by executives using IS for decision making. The IS manager must know the organizational business/ decision problems before deciding on how much, when, and in what way prototyping and other approaches should help to solve them. In summary, this study represents a contribution to the literature for two reasons. First, this study empirically verifies the advantages of prototyping in practice from IS managers’ perspective and opinion, and provides some evidence to corroborate the claims for prototyping in the literature. Second, it provides a practical and relatively strong test of the claimed advantages of prototyping in the context of executive IS because it crossvalidates the list of problems using separate groups

T. Guimaraes, J. K Saraph / Prototyping

of business executives; and a relatively large number (109) from many different 40 business organizations

263

it collected data from of business executives functional areas within of different size and

type.

References J.C., “Evolutionary Strategy PI Alavi, M., and Henderson, for Implementing a Decision Support System”, Management Science, Vol. 27, Number 11. November 1981, pp. 1309-1323. 121Alavi, M., “An Assessment of the Prototyping Approach to Information System Development”, Communicatrons of the ACM, 27, 6, June 1984, pp. 556-563. Interaction Important 131 Alter, S., “Why is Man Computer for Decision Support Systems?’ Interfaces, Vol. 7, No. 2. February 1977, pp. 109-115. D.S., “Data-Driven Prototyping”, DATAMA141 Appleton, TION, November 1983, pp. 2599268. T. and Wetherby, J.C., “Heuristic Develop151 Berrisford, ment: A Redesign of Systems Design”, MIS Quarter/y, Vol. 3, March 1979, pp. 11-19. Prototyping: A Life Cycle Perspec161 Boar, B.. “Application tive”, Journal of Systems Management, February 1986. pp. 25-31. Versus Specifying: A I71 Boehm. B.W., et al., “Prototyping Multiproject Experiment”, IEEE Transactrons on Software Engrneering, SE-lo, 3, May 1984, pp. 290-302. Requirements PI Bui, T., and Jarke, M., “Communications for Group Decision Support Systems”, Journal of Management Information Systems, Vol. 2, Number 4, Spring 1986, pp. 8-20. Consensus Seeking Algorithm for [91 Bui, T., “NAI-A Group Design Support Systems”, Proceedings of the 1985 IEEE Internatronal Conference on Systems. Man, and Cybernetics, Tucson, Arizona. 1985. Distributed Systems De1101 Des Jardins, R., “Evolutionary sign”, Proceedings of the 1st International IEEE Computer Software Applications Conference, Institute of Electrical and Electronic Engineers, New York, 1977. Dll DeSanctis, G., and Gallupe, F., “Group Decision Support Systems: A New Frontier”, Database, 2, 1985, pp. 3-11. Prototyping Methodology: A 1121 Doke, E.R., “Emerging Taxonomy”, Proceedings of Deckon Sciences Institute, Vol. 1. 1987, pp. 413-414. Design by Trial and Error”, P31 Frank, J.W., “Applications Infosystems. September 1979, pp. 13-19. vs. Prototyping Methodology”, 1141 Frank, W.L., “Structured Computerland. August 15, 1983. pp. 51-52. T., “Prototyping: Orchestrating for Success”, WI Guimaraes. Datamation. December 1, 1987, pp. 101-106. T., “DSS for Top Executives: Obstacles and [I61 Guimaraes, Bridges”, International Journal of Information Management, 7, 1, March 1987, pp. 21-35. and the Systems Development 1171 Harrison, R., “Prototyping Life Cycle”, Journal of Systems Management, August 1985, pp. 22-25.

264

U81

Research

Information

Huber,

G.,

Support

Systems”,

“Issues

[191 Janson, M.A., Development: cember

M.,

Keen,

of

Group

“Prototyping

Appraisal”,

MIS

for Systems Quarferly,

M.T., a

and

Shakun,

Negotiations

M.F.,

De-

Support

System”,

P.G.W.,

“Value

Analysis:

MIS

Justifying Vol.

Quarterly,

Keen,

P.G.W.

Systems:

ley. Reading, [23]

Kruashaar, Method

MA,

Morton,

MS.,

“Decision

Perspective”,

J.M.

and

Systems

L.E.

Shirland,

Development

Specialists”,

“A

Prototyping

by End Users

MIS

PI

Licker, Group

P.,

and

Hall, 1986. Thompson,

Support

R.,

“Consulting

and

B.P.,

Issues”,

Vol. 1. 1988,

WI

McCracken,

and Kathawala,

Proceedings

senting

Y.,

D.D.,

Position”,

“Software

Proceedings of Conference on System

of Decision

Sciences

Models

Institute,

17. 1980. pp. S-10.

M.A.,

Analysis

as Application

“Decision

Problems

of

Developers”,

pp. 37-46.

Getting

Planning

and

Large-Scale

DSS

MIS Quarter/y, Vol. 10, June 1986, pp. 159-177. J.D.,

and

Jenkins,

for Systems

Vol. 6, September

1982,

A.M.,

“Prototyping:

Development”,

The

MIS Quarterly.

pp. 29944.

Wiley & Sons, New York,

[341 Odell, P., “Development rions, March 25, 1986. 1351 Rockart,

J.F.,

Needs”,

“Chief

NY,

1969.

Methods Executives

pp. 360-414.

Meld”, Define

Computer Their

Harvard Busmess Reurew, March-April

Decr-

Own Data 1979,

pp.

81-93. R.J.,

DSS”,

“A Model

of Organizational

Data Base, Vol. 12, Numbers

Variables

for

1 and 2, 1980,

pp.

63-72. [37]

Shakun,

M., “Decision

Support

Systems

for Negotiations”,

Proceedqs of the 1985 IEEE International Conference on Systems, Man, and Cybernetics, Tucson. Arizona, 1985. [38] Sprague, R.H., and Carlson, E.D., Building Effectiue Decision Support Systems, Prentice-Hall, Englewood Cliffs. [39] Sprague, Decision

R.H. Jr., “A Framework Support Systems”, MIS

ber 4, 1980. in the 80’s: Perils and Prom-

and Jackson,

Users

NJ, 1982. “Prototyping:

Extra, September Systems

The

Holland.

Ill-Structured Prob[331 Newell, A., “Heuristic Programming: lems”, In Progress in Operations Research, Vol. 3, John

pp. 416-417. D.D..

ises”, Computerworld

~291 McCracken,

Systems:

by One Person”,

the 8th Annual Hawari International Sciences, Hawaii, 1985, pp. 466-475. ~271 Lingraj,

Started”,

[361 Roland,

Prentice

Decision

C.L.,

~321 Nauman.

1985.9.

Quarterly,

pp. 189-197.

NJ:

Support

and

Computer Dew ~241 Kull. David, “Design on Development”, sions, April 9, 1985, pp. 866105. Englewood v51 Lantz, K.E., The Prototyping Methodology, Cliffs.

et al.,

Support

Addison-Wes-

1978.

for Applications

Information (3)

and Scott

An Organizational

North

[311 Meador,

Sup-

l-15.

GQI

Elsevier

pp. 551-553. 1979.

in

pp.

editors, 1981,

Vol. 3, December

New Paradigm

1981,

al.,

“End

Analysis:

Policy

Decision

5, March

et

Holland,

[301 McLean. E.R.. MIS Quarterly,

“MEDIA-

Evolutionary Systems Design Under Complexity, Holden Day, 1985.

W.W.,

Amsterdam,

pp. 3055316.

Jelassi.

port Systems”,

man,

Decision

M.F.,

Making

Pll

Design

L.D.,

A Critical

Towards

Shakun,

the

and Smith,

1985,

]201 Jarke, TOR:

in

MIS Quarterly. 8, 3, 1984, pp. 195-204.

& Management

“A Minority

and Design,

Dis-

Cotter-

[40]

Stohr,

for the Development

Quarter/y,

of

Vol. 4, Num-

pp. l-26.

E., “DSS

for Cooperative Decision-Making”, Proceedings NATO Conference on Database and Decision Support Systems, Amsterdam: North Holland, 1981.

Information

T. Guimaraes, J. K Saraph / Prototyprng

& Management

265

Appendix A Executives’

Evaluation

Problem Type

of Problem

Frequency

Problem Number

and Importance

(n = 109) Frequency

Importance

3.5 3.6 4.1 (1.2) 3.9 (0.9)

5.9 5.8 6.3 (0.6) 6.5 (0.7)

4.0 (0.9) 2.4 (0.6)

4.8 (1.3) 5.2 (1.6)

3.8 (0.9)

6.1 (0.8)

2.8 (0.5)

5.4 (0.5)

3.6 (1.2) 3.6 (0.7) 3.1 (0.8)

6.7 (0.4) 6.3 (0.8) 6.6 (0.5)

3.3 (1.3)

5.3 (2.2)

3.4 3.0

5.9 6.5

Inability to define information requirements clearly Inability to communicate problem specifications to people trying to define information requirements and/or construct models

2.4 (0.5)

6.6 (0.6)

3.5 (0.9)

6.4 (0.6)

If computers not knowing to use

4.3 (0.6)

4.2 (1.1)

3.4

6.0

3.3 (0.8) 3.5 (0.7)

6.6 (0.4) 5.4 (0.6)

3.3

4.8

3.4 (1.1)

4.9 (1.8)

2.8 (0.8)

3.8 (1.4)

3.1 (0.9)

4.1 (2.3)

3.1(0.7)

6.2 (0.9)

Problem Description

1, Performance (a) Timeliness 1. 2. 3. 4. 5. (b) Cost Effectiveness (c) Quality (d) Flexibility (e) Reliability (f) Lack of control 2. Systems Development (a) Problem Definition

10.

11. 12.

Long lead times to get information Long lead times to have technical problems solved Using the computer is too time consuming Even “friendly” computer languages takes too long to learn Computer related trouble shooting is difficult and frustrating With hindsight, the system is not cost/ beneficial Poor quality of available reports Inflexible systems (difficult to change) Unreliable systems (poor response time or down time) Losing touch with the data and/or model

(b) System Design 13.

are likely to be useful what is the best alternative

(c) System

development 14. 15.

Necessary data not available System development requires too much time and energy up frong with no results for some time

3. Executives’ lack of knowledge 16. 17. 18. 19.

Frequency = The average and standard 2 = seldom, 3 = sometimes, 4 = often, 5 = Importance = The average and standard portant, 2 = quite important, 3 = slightly portant).

Not knowing when computers would be useful Not knowing which software packages or new programs are available Not knowing how to use specific software packages and programs Lack of information about relevant data sources inside and outside the organization

deviation (within parentheses) for how often the problem is encountered (1 = never, always). deviation (within parentheses) for the problem importance rating (1 = extremely unimunimportant, 4 = neither, 5 = slightly important, 6 = quite important, 7 = extremely im-

Informalron & Management

Research

266

Appendix B MIS Managers

Rating

of Solutions

in Operation

for Over Two Years to Address

(n = 34) Average Item Effectiveness

Problem Number

Problem

1. Lack of performance (a) Timeliness

1.

Long lead times to get requested information - Fourth Generation Languages/Report Generators _ Personal Computing - Prototyping - Coaching _ Application Development Center Long lead times to have technical problems solved _ Help Desk/Hot Line - Coaching - Technical Support Function Using the computer is too time consuming - Systems Analysts, User Liaison, etc. - Systems Developers - Turnkey Systems - Prototyping - Coaching Even “friendly” computer languages take too much time to learn - Training Program - Coaching - Help Desk Computer related trouble shooting is difficult and frustrating - Help Desk - Coaching _ Technical Support Function With hindsight, the system is not cost beneficial - Prototyping - Promote End-User Development - Charge Back System - Coaching - Help Desk Poor quality of available reports Systems Analysts, User Liaison, etc. - Survey of User Opinion - Testing Through Report Stoppage - Prototyping

3.2 2.9 3.5 2.1 1.6

(26) (18) (14) (26) (14)

3.2 2.1 3.5 3.8

(22) (19) (24) (26)

Inflexible systems (difficult to change) _ System Maintenance Function/Standards - Fourth Generation Languages/Report - Prototyping

2.6 (26) 3.4 (34) 3.1 (26)

(b) Cost Effectiveness

(c) Quality

and Related

Problems

Type

Problem

Description

Executives’

Items

3.6 (34) 3.5 (27) 3.3. (26) 2.9 (9) 3.6 (14) 3.3 (20) 2.4 (29) 3.6 (21) 2.9 3.4 2.7 3.5 2.9

(25) (28) (34) (21) (29)

3.2 (24) 3.8 (29) 3.4 (26) 3.7 (26) 3.1 (29) 3.2 (21)

(d) Flexibility

Generators

(e) Reliability

(f)

Lack of control

10.

Unreliable systems (poor response _ Help Desk - Coaching _ Technical Support Function Personal Computing - Tune-up Maintenance - Quality Assurance

time or down time)

Losing touch with the data and/or _ Systems Analysts, User Liaison, - Systems Documentation

the model etc.

2.9 2.5 3.4 3.6 3.6 3.4

(20) (18) (22) (19) (25) (17)

3.1 (34) 2.4 (27)

(81) 9’5 (9) Z‘E (LI) L’E

P’Z

(IZ)

P’E

(21)

ap!slno

pue ap!su! a3Jnos imp lueAqala1 l"Ocp

uoyGmJJoJu! JO ‘IJET

Pa

dlaH Byqmo~

(62) 6.C

‘61

-

(PZ) 9’E ‘81 (62)

I’C

(9Z) 9.2 (IZ) 8’2 ‘332 ‘“OS!“!-, JaSn ‘SlS.@UV SUJalSi(~ -

(PC) L’C

JOJ pas” aq UP?3 sureJ%oJd ~a” Jo sa%qxd

a~eml~os )uaJa~~~p xsqm %u!mouq ,ON 8U~Xeo~

(62) SE (9z) 9’C (10

uogeJwuomaa

E’E

wa dlaH )uawd!nbg Bu!d.iloloJd

(sr) 9’2 ‘31a ‘UOS!E!~ ,asn

(PC) 6°C

[n~asn aq p[no~ smndmo3

‘s~sQ2uv

Jado[aAaa

(PE) SE

‘LI

--

sLUa,s.Lg -

uaqm Ou!mouy ,or\l

ysaa

(IZ) E‘Z (8)

d[aH

swalsi(g

‘91

-

UJr?J8OJd %U!U!EJL -

L.1

S’I

(61)

<‘I

(61)

%!d/(lOlOJd

X’E

(9Z)

uoy23npzJ

(PZ) L‘C

-

amy awes Isv,al w J~J sl[nsaJ ou ql!rn IUOJJ dn BJaua

put? aw!i qmm 001 saJ!nbaJ luawdolamp sa!Jol3aJ!a

asea

mavds

pzuJalxg

rtlt?a

Tsaa dlaH

‘5-l -

(108‘1 (PI) p‘t ‘PI

(Zl) 6‘t

luaLudo[aAaa s”wi(g

E’Z

(9Z)

1.E

(62)

8uyEo3 ?saa

d[aH

Ou!di(,olOJd

(1s) Z‘E ma ‘uos!eg

(PC) L’E

Jasn

‘sisdpx~~

suaisK(g

asn 01 ayiwJaip2

(3)

tsaq ‘EI u%!saa

wsb

Z‘E

(92)

9‘Z

(PO

L.C

(9Z)

%u!dhlolOJd 3ia ‘uos!eg yapom

Jasn

13n~lsuon ~o/pUv sluawaJ!nbaJ

%U!LJI aldoad 01 suo!wxJ!3ads

‘~shp2~v smals/(g

‘uospx~

(q)

-

01 ,Q!1!qwI

%!dklolOJd swawJ!nbaJ

-

uo!,eur~o~u~ augap 01

ura[qoJd a~tym.Uwoo

3a

(PC) 1’E

Jasn

‘IS&~JV

uoyw~~o~u~ auyap t+cap

‘ZI

-

smalsLg

-

01 6lyqaUI

‘II no!l!ugaa ~“T-PJd

1uaLudqahaa

(E)

suJavAg .c