The Manager-Analyst Interface in Systems Development

Manager-Analyst Interface

The Manager-AnalystInterface inSystems Development*

By: Kate Mo KaiserWilliam R. King

A bstractThe user-analyst liaison function in system develop-ment was studied in thirty-eight large firms using astructured interviewing process. The study revealedthat the most prevalent form of liaison is still thetraditional systems representative and that the liaisonfunction is generally performed much less formally thanthe IS literature would suggest. However, a trendtoward greater formalism was detected. Other aspectsof the liaison function, such as perceptions of the role,relevant career paths, and attitudes toward the functionwere also studied.

Keywords:Information Analyst, liaison, systemsdevelopment, project teams, userinvolvement

ACM Categories: 1.52, 1.59, 2.42, 2.45, 3.30, 3.50,

3.51

¯ The authors would like to thank the Richard Irwin Foundationfor funding a portion of the study and Jeff Meacham of ArthurAndersen for his helpful comments.

The modern concept of a management informa-tion system (MIS) encompasses the integratedoperation of diverse elements--hardware, soft-ware, databases, people, and procedures.Perhaps the weakest link in this overall system ofresources is that involving the formal and informalinteractions between systems personnel andusers [13, 15].

The benefits to be achieved by managers, whoare the primary intended users of MIS’s and deci-sion support system (DSS’s), must be the resultof the effective manipulation, design, anddevelopment of hardware and softwaretechnology by analysts. As computer systemshave become more complex, this dependence ofusers on analysts has become even greater [8].

It is not surprising, therefore, that the "user-analyst interface" has been the subject of inten-sive scrutiny [1, 5, 11, 15, 17, 19, 21, 22, 26,28, 29, 30, 31]. Some of this attention hasfocused on the characteristics of users that serveto hinder the interaction, such as their lack ofunderstanding of the computer capabilities andtheir less-than logical problem-solvingapproaches [3, 6, 7, 24, 25}. On the other hand,attention has also been devoted to analysts’logical and analytical nature and their lack ofappreciation of managerial realities I4, 13, 18,20, 23, 31, 33].

The practical resolution of the problems that arepresumably caused by differences betweenanalysts and user-managers in background,cognitive style, and other factors will undoubtedlynot be resolved by simplistic solutions such astraining more analytically oriented managers ormore business-oriented analysts. The differencesthat exist, whether they are intrinsic or merelylearned as the result of past practice, areprobably too great. Moreover, the "knowledge-demands" of each function are so great as topreclude the development of "Renaissance Men"who can know their primary field as well as that ofa second field that is quite different in nature andin skill requirements.

Since the two different organizational groups(analysts and user-managers) must necessarilyinteract for an MIS development effort to beproductive, there will always be the need for aninterface, or liaison, function--here termed the"information analyst" (IA) function.

MIS Quarterly~March 1982. 49


This article empirically addresses the variousways in which the IA function is, in fact, beingfulfilled in modern business organizations. It alsoassesses attitudes related to the relative effec-tiveness of the various methods. The notion of an"evolutionary path" through which organizationsmay progress with respect to the methods thatthey use to perform the IA function is alsostudied.

The InformationAnalyst FunctionThe "information analyst" term for describing theuser-analyst interface function is adopted fromthe report of a committee of the Association forComputing Machinery for the creation of aposition of information analyst for one who is"people-oriented or organization-oriented andviewed by some as evolving out of the ’methodsand procedures’ positions of less complicatedtimes" [2, 12]. The systems analyst iscorrespondingly described to be "computer ortechnology-oriented." These reports offer noempirical evidence, but discuss the problems ofthe user-analyst interface and present a cur-riculum that is designed to equip an individual withthe skills that are deemed necessary to performthe IA function.

Thus, one way of performing the interface orliaison function that is here termed the "IAfunction" is to create an IA position that is filled bya person having some knowledge and skills inboth areas--managerial and analytic. The "IAposition" approach to performing the IA functionis shown schematically at the top of Figure 1.Three other prototypical methods for perform-ing the function are also shown there and

respectively termed "User-Coordinator,""Systems Representative," and "Dual-Coordinators." Each of these methods, as well asothers, is described in the literature.

The Formal IA model represents the realization ofthe ACM [2, 12] proposal for the creation of acurriculum that would train individuals to fulfill theIA function directly. Schematically, this is shownin Figure 1 as locating the IA function on a con-tinuum midway between the user and the analystbecause the IA is trained in both analysis andmanagement and because the position is theembodiment of the function in this case.

The User-Coordinator (UC) model describes thesituation in which the IA function is performedlargely by an individual in the user organization.Generally, that person possesses some com-puter skills and/or experience to complement thebasic "user knowledge." Then face-to-faceinteractions with the computer analysts are con-ducted and the individual acts as a focal point forother interactions. Often, this role is informal andnot codified by a job description. The UC isshown in Figure 1 to be "closer" to users than toanalysts.

The Systems Representative (SR) is the mirrorimage of the UC. Many DP departments assignspecific systems analysts to work only with par-ticular divisions or departments. This "systemsrep" may be one of several assigned to a userdepartment or an SR may handle several divi-sions. Over time, an SR comes to acquire someknowledge in the assigned user business area.As well, rapport with the users may beestablished that should facilitate the performanceof the IA function. Figure 1 shows the SR to be"closer" to the analysts than to the users, sincethe SR is an analyst by training and receives pro-motions, evaluations, etc., in the computerdepartment.

Formal IA User ~

User-Coordinator User ~. "~-~ UC

Systems Rep User ~

Dual-Coordinators User ~-- ~" UC

<

~_ Analyst

~:~ Analyst

SR-~.~" "~/ Analyst

SR~" i Analyst

Figure 1. Information Analyst Function Prototypes

50 MIS Quarterly~March 1982


The Dual-Coordinator (DC) model represents combination of the UC and SR models. Thisapproach is often seen as a safe way to go, fortheoretically, it promises to reduce conflict byinvolving both groups who are involved in asystems project through their respective focalpoints. Most of the time this arrangement is tem-porary, because it is structured only for a par-ticular systems development project [ 10]. Figure1 shows the DC prototype as a literal combinationof the UC and SR models.

Study Objectives

Moreof:

The study has the broad objective of investigatingthe degree to which the extensive MIS literatureinvolving the user-analyst interface has had prac-tical impact on the way in which MIS’s are actuallydeveloped.

specifically, the study has the objectives

a. identifying the various ways in whichthe IA function is actually performed inlarge business firms,

b. assessing attitudes related to theeffectiveness of the various proto-types, and

c. determining whether there is an"evolutionary path" through whichfirms progress with respect to the IAfunction (similar to the "stages ofgrowth" phenomenon that has beenidentified for computer systems [27]).

Methodology of the StudyTo accomplish these objectives, a survey ofusers, analysts, and IS managers was conductedin thirty-eight "Fortune 500" business firms.Initially, a pilot study was conducted in thirteenfirms to develop and validate the prototypes inFigure 1 and the instruments to be used in theremainder of the study. This pilot study involved acombination of phone, mail, and personal inter-views with systems managers and users in eachof the firms.

Several prototypes not included in Figure 1 aresuggested from both the MIS literature and thepilot study. The "gatekeeper" is often a topmanagement official and/or systems director whois sought for approval at certain stages. Almost allprojects have this function being performed, butactual participation as a liaison was found to beminimal. The "generalist" analyst services anyuser as resources allow. This prototype wasfound to be virtually nonexistent. The user whoworks directly with the computer is anothertheoretical way of performing the IA function, butno instance of this method could be found inpractice.

Thus, although the study had initially contemplateda larger number of IA prototypes than the fourdiscussed earlier, other varieties were not, infact, identified in practice. Therefore, the fourprototypes labeled IA, UC, SR, and DC in Figure1 form the basis for the study.

Operationally defining theIA prototypes

In order to obtain meaningful data concerning thefour IA prototypes, they must be operationallydefined. The pilot study indicated that the follow-ing variables could be used to empiricallydistinguish among the four prototypes:

¯ reporting department,

¯ requirement for DP skills,

¯ requirement for user department-related skills,

¯ ratio of time spent using user andsystems skills,

¯ formal designation of liaison function,and

¯ per cent of time spent Jn liaisonfunction.

Relevant levels of each of these factors werejudgmentally developed and operational criteriafor identifying the four prototypes were tested inthe pilot study. These levels are shown for thefour IA prototypes in Table 1.

Table 1 shows that since the IA is the "pure"liaison, there were no stipulations made about

MIS Quarterly~March 1982 51


Table 1. Operational Measures for IA Prototype Identification

Variable

Reporting dept.

Years in systems dept.

Years in systemseducation *

Years in user dept.

Years in usereducation* °

Ratio of systems/user skills on project

Skills required for theproject

Designated liaison

Informal liaison

% of time as a liaison onproject

Information Systems User DualAnalyst Representative Coordinator Coordinators

(IA) (SR) (UC) (DC)

systems user

>0

>0 >0

>0

>0 >0

both S & U S U S U25-75% > 75% < 25% <25% >75%

or both 25-75% or both 25-75%

both user or both systems or both

yes yes yes

or (no) or (no)

and (yes) and (yes)

75% > 25% > 25%

°A straight line indicates that this variable was not used in the criterion.° "Includes on-the-job training.

education and experience and a balanced mix ofboth user and systems skills were deemed to ben~cessary. The formal IA. must be formallydesignated as a liaison and must spend at least75% of the time in that role.

The Systems Rep (SR) reports to a systemsdepartment and spends time in both systems anduser education, though having spent time in auser department is not required. The mix of skillsfor the Systems Rep would be more toward thesystems area (more than 75% systems orientedand less than 25% user oriented), or could bemore balanced (25%-75% mix of both user andsystems skills), although the Systems Rep must

perceive that user skills or both were necessary.The liaison designation need not be formal, butthe Systems Rep must report acting as a liaisoninformally if not formally appointed. A minimum of25% of one’s time was considered to benecessary in performing this role.

The User-Coordinator (UC) requirements arebasically the complement of the SR. The UC’sexperience and education are minimal in the userarea and systems education cannot be lacking.Though the skills employed on the project wouldbe more user oriented, the UC must recognizethe need for systems skill. The liaison role (as withthe SR) must at least be an informal self-perception.



The sampleSystems and user personnel in thirtY-eight"Fortune 500" firms were interviewed in theprimary study. Table 2 shows a breakdown of theindustry, size, and level of the organizationsinvolved. In twenty-two of the thirty-eight firms,the interviews were conducted at the corporatelevel, whereas in the other sixteen, it was at alower level, e.g., divisonal.

Discriptive data for the data processing functionsin the third-eight firms are given in Table 3 interms of the frequencies of the modal values. Forinstance, in twenty of the thirty-eight firms, the DPstaff size was greater than 300, and in thirty-oneof the firms, analysts were said to stay on theaverage for more than three years. All three of thepossible responses to "degree of DP centraliza-tion" are shown in the table since there was noclear modal value.

Well over half of the firms reported that the headof the MIS function was two or fewer reportingsteps from the chairman or president, thusempirically confirming the anecdotal evidencethat has recently appeared in the business press[14, 32]. One MIS director stated that he insisted

that he report directly before he accepted theposition. Among the resources on which thesystems department could draw was "visible" topmanagement support. However, outside con-sultants and outside applicants’ packages werenot found to be much used. The DP budgets werefairly trim with many (24) under 1% of net sales(financial firms used operating expenses as measure and, therefore, are not comparable).One director boasted a .4% figure. Only six of theDP "shops" were non-IBM.

Assessment of sophistication was varied acrossthe sample firms. Most firms had been formallymanaging data for over twenty years. The Gibsonand Nolan [16] model of stages of computerdevelopment was applied and most firms werefound to be in the two middle stages "contagion"and "control." Respondents were allowed multi-ple responses on this and the technicalsophistication measure. The measure fortechnical sophistication is one developed byChurchill, et aL [9]. They described four stages ofcomputer development. Systems managers wereasked which stage or stages describe the pur-pose for most of their existing and developingapplications. The four types were: handling data

Table 2. Characteristics of Participating Firms (N = 38)

Industry

Sales orAssets

Structure*

Mining and Manufacturing 24

Transportation & Communication 4

Financial 10

> $10 billion 6

$5-10 billion 7

$1-5 billion 19

< $1 billion 6

Corporate* * 22

Division 7

Subsidiary 9

R̄efers to location of the interview.¯° Most have subsidiaries and some of these subsidiaries have their own OP staff.



Table 3. Data Processing Characteristics

Characteristic

DP Staff

size

years most programmer/analysts stay

DP Structure

centralization

steps MIS head is frompresident or chairman

Resources

top management support

% time outside consultantsused

% time outside applicationpackages used

% DP/overall budget

mainframe vendor

Sophistication

age of formal department

Stage of computerdevelopment*

technical sophistication *

Modal Value

> 300

>3>5

centralizeddecentralized

mixture

<2

Visible

<2%

<2%

<1%

IBM

> 20 years

contagioncontrol

operationalcontrol

(N = 38)Frequency

2O

3117

141013

23

24

18

19

24

32

28

2O19

26

* These variables allowed multiple responses.



faster, creating new information, operational con-trol, and stategic planning.

To permit the gathering of data concerning the IAfunction it was determined that a specific projectwould be identified in each firm and used as theframe for further data gathering. This was done toobviate the effect of any differences that mightexist between the "theoretical" responses givenby an MIS director and the way in which the IAfunction is actually performed on a given project,as well as to provide a basis for obtaining datafrom users as well as from analysts.

To this end, each of the firms was asked to iden-tify a particular MIS project that had beenimplemented in the most recent six months, andwhich "involved user participation" for which fur-ther data would be gathered. These projectswere then used as the basis for the identificationof individual analysts and users who responded toa survey instrument, some of whom were alsopersonally interviewed. Data were collected from105 individuals who were participants in thirty-three’ different projects involving sixteen differentnamed user departments (accounting, purchas-ing, etc.). The range of systems was wide, withthe modal budget being over $100,000 and themodal number of users being 50.

Results of the StudyThe frequency of the four prototypes; asassessed based on responses to questionsrelated to the variables and levels defined in Table1, is given in Table 4.

Table 4. Frequency of Liaison Prototypes

Prototype # of Projects

Formal IA 0

Systems Rep 15

User-Coordinator 3

Dual-Coordinator 2

’Of the thirty-eight participating firms, only thirty-three provided"’complete data."

Only twenty of the thirty-three projects actuallyused some form of IA prototype.~ The other thir-teen projects did not use any prototype, despitethe fact that in some cases it was the firm’s statedpractice to do so. This is a somewhat surprisingfinding, especially since MIS managers wereinitially told the objective of the study and wereallowed to select projects for further study withrelative freedom. One would think that this wouldlead them to select projects in which the interfacerole to be studied was, in fact, formalized. Thefact that only 60% of the projects was found tohave any formalized interface responsibilityassigned would therefore seem to be contrary tothe "prevailing wisdom" in MIS.

The most traditional prototype -- the SR -- is byfar the most prevalent one. The formal IA is,somewhat surprisingly, not found in this sample.Based on the results of the pilot study, the criteriafor designating a liaison as an IA were establishedto be "less rigorous" than those for the otherprototypes (see Table 1 ). This suggests that theformal IA is indeed a rarity in the real world of MISdevelopment.

The low proportion of UC and DC models is alsosomewhat surprising, since the projects wereselected on the basis of "user involvement." Thiswould be expected to bias the results towardmore formalized user involvement. However, inonly about 15% of the projects was there suffi-cient formalized user involvement to justifydescription as either a UC or DC prototypeaccording to the criteria in Table 1.

The criterion from Table 1 that precluded describ-ing some respondents as formal IA’s was the"percent of time spent as a liaison." There wereonly two people in the entire sample whoresponded that they spent more than 75% oftheir time as a liaison. Only eight of 105 said thatthey spent more than 50%, even though forty.nine of 105 said they were designated formally asliaisons.

This is especially interesting in Iight of the resultsof the pilot study. Many people in the preliminarysurvey said they were fulfilling the liaison function.But in the main study, when respondents were

~The twenty projects that utilized one or another o! the liaisonprototypes involved a total of twenty-three such people sinceeach "Dual Coordinator" involves both SR and UC andbecause one other project utilized two SR’s.



asked directly about time spent in this role, fewsaid that actually entailed much time.

Perceptions of the IA role

To validate the formal classification shown inTable 4, users and analysts associated with eachproject were asked to identify the individual per-forming the IA function. Of the twenty-three peo-ple who were formally identified as performingthis role, twelve were unambiguously identified byall project participants, and four were identified bysome participants. Seven of the twenty-threewere not identified even though they met theformal criteria of Table 1.

Since the study involved recently completed pro-jects, memory problems should not have beensignificant. This suggests that the IA function isgenerally performed much less formally than isgenerally thought to be the case.

Reporting department of IA

Although "reporting department" is used as oneof the classification criteria in Table 1, the evolv-ing results of the study suggested that a prevalent"user orientation" was not being detected usingthe formal criteria described there. To assess thisfurther, the respondents were classified accord-ing to the other criteria only. Table 5 shows thethirty-eight IA’s identified according to these"relaxed" criteria categorized by their reportingdepartment. These data clearly show thepredominant influence of the systems depart-ment, since a clear majority of individuals whomight be classified as UC’s by all other criteria, infact, report to the systems department.

Career path of IA’s

The career path of IA’s was addressed by deter-mining whether each IA’s previous experienceinvolved the "other side" of the user-analystdichotomy, and whether, they were advanced totheir present position or hired externally. Of thefive individuals based in user departments (thethree UC’s and the user members of the DC inTable 4), four had previous systems experience.Of the eighteen systems-based people, only fourhad previous user-department experience. Of thetwenty-three, sixteen came to their present posi-tion through internal promotion.

These data indicate a lack of user experience onthe part of analysts that is perhaps understand-able. However, they further amplify the lack of"user involvement," even in terms" of priorexperience of the IA, as indicated previously.

A ttitudinal data

All 105 respondents were asked to provideattitudinal data indicating their level of agreementor disagreement with a set of standards related tovarious dimensions of the systems developmentproject. The response patterns were tested todetermine if attitudes are related to the IAprototype in use. A series of null hypotheses ofthe form, "Attitudes are no .different for those par-ticipating in development projects under’SR, UC,and .DC models," were tested using one-wayanalysis of variance.

Table 6 shows the relevant statements andindicates those on which the level of significancewas below 0.1. This table shows some possiblerelationship between attitudes and IA prototype,especially in terms of attitudes toward awareness

Table 5. Reporting Department of Individual Performing IA Function

Reports to:

User Dept. Systems Dept. Other

SR 2 1 9 0

UC 4 1 1 2

56 MIS Quarterly/March 1982


Table 6. Attitudinal Hypothesis Test Results

Item

1. Too many people involved

2. Usually in agreement

3. Little turnover

4. Handled conflicts about procedures well

5. Lacked communication skills

6. Adaptable to change

7. Felt restrained by budget restrictions

8. Aware of user problems

9. Aware of systems problems

10. Should have met more frequently

11. Systems participants heavily involved

12. User participants heavily involved

Level of Significance

.096

X

X

.08

.091

X

X

.094

.031

X

X

X

of systems problems. This particular measure isintuitively appealing since most of the liaisons areSR’s. It is interesting that a difference inprototype is significant (.1) on awareness of userand systems problems (Item 8 and 9), but thatthere was no significant difference among theUC, SR, or DC with regard to actual involvementfrom user and systems participants in the group.

Trends in Prototypes

Data were gathered concerning the interfacefunction as it was performed in the years 1976,1979, and 1982 (estimate) in order to assesstrends. Each systems manager was asked toestimate the frequency of each prototype in eachtime period. For those twenty-three firms thathad, at one time or another, some IA prototype,the (null) hypothesis of no difference wasrejected at the 0.005 level for both three-yearperiods.3 Viewing the data as one set by using allthree time periods simultaneously yields the sameresults." Thus, there is an indication of a trendtoward greater formality in the way in which the IAfunction is performed in these firms.

~Wilcoxon matched pairs signed-ranks test"One-way analysis of variance

Summary and ConclusionsThis study suggests a clear difference betweenthe literature and practice of MIS as it relates tothe manager (user)-analyst interface. SystemsRepresentatives still dominate the process of MISdevelopment. Other methods for performing theliaison or interface role are less frequently used.The formal information analyst, much discussed inthe literature, does not appear in the sample at all.

Less time was devoted to the interface functionby those designated to perform it than might beexpected. Moreover, even liaisons who aredesignated as "User-Coordinators" were found tooften report to the systems department ratherthan to the user department.

While a trend toward greater formalization of theIA role was detected, the overall results of thisstudy present a negative picture for those whobelieve that a greater "user orientation" is criticalto progress in MIS. The disparity between theoryand practice appears to be great, despite thedecade or more that has been devoted todiagnosing and prescribing remedies forproblems at the user-analyst interface.



References

[1] Andersen, W.S. "The Expectation Gap,"Journal of Systems Management, Volume29, Number 6, June 1978, pp. 6-10.

[2] Ashenhurst, R.L., ed. "Curriculum Recom-mendations for Graduate ProfessionalProgram in Information Systems," Com-munications of the ACM, Volume 15,Number 5, May 1972, pp. 363-398.

[3] Austin, J.E. "Educating Management in theUse of Information Systems," AdvancedManagement Journal, Volume 40, Number2, New York, New York, Spring 1975,pp. 37-42.

[4] Bartol, K.M. "Building Synergistic EDPTeams," in Willoughby, T. ed., Proceedingsof the 15th Annual Computer PersonnelResearch Conference, August 18-19,1977, Association for ComputingMachinery, New York, New York, 1977,pp. 18-30.

[5] Benbasat, I., Dexter, A.S., and Mantha,R.W. "Impact of Organizational Maturity ofInformation System Skill Needs," MISQuarterly, Volume 4, Number 1, March1980, pp. 21-34.

[6] Benjamin, R.I. Control of the InformationSystem Development Cycle, Wiley-Interscience, New York, New York, 1971.

[7] Bostrom, R.P. and Heinen, J.S. "MISProblems and Failures: A Socio-TechnicalPerspective, Part h The Causes," MISQuarterly, Volume 1, Number 3,September 1977, pp. 17-32.

[8] Burack, E. and McNichols,. T.J. "HumanResource Planning Technology, Policy andChange," Technology, Computers, andManpower, CARl, Kent, Ohio, 1973.

[9] Churchill, N.C., Kempter, J., and Uretsky,M. Computer-Based Information Systemsfor Management: A Survey, NationalAssociation of Accountants, New York,New York, 1969.

[10] Cteland, D.I. and King, W.R. SystemsAnalysis and Project Management,McGraw-Hill, New York, New York, 1975.

{11] Cotterman, W.W. Computers in Perspec-tive, Wadsworth Publishing Company,Belmont, California, 1974.

[12] Couger, D.J., ed. "Curriculum Recommen-dations for Undergraduate Programs inInformation Systems," Communications of

the ACM, Volume 16, Number 12,December 1973, pp. 727-749.

[13] Coverdale, S. "A New Method fo~ Improv-ing Communications Between User Groupsand Systems Specialists and Its Impact onSystems Development Efforts," inWilloughby, T., ed., Proceedings of the15th Annual Computer PersonnelResearch Conference, August 18-19,1977, Association for ComputingMachinery, New York, New York, 1977,pp. 80-93.

{14] Crane, J. "The Changing Role of the DPManager," Datamation, Volume 28,Number 1, January 1982, pp. 97-108.

[15] Dickson, G. and Simmons, J. "TheBehavioral Side of MIS," BusinessHoriZons, Volume 13, Number 4, August1970, pp. 59-71.

[16] Gibson, C.F. and Nolan, RoL. "Managingthe Four Stages of EDP Growth," HarvardBusiness Review, Volume 52, Number 1,January-February "i 9.74, pp. 76-88.

[17] Glaser, G. "The Centralization vs. Decen-tralization Issue: Arguments, Alternativesand Guidelines," Data Base, Volume 2,Number 3, Spring 1973, pp. 1-7.

[18] Henry, R.M., Dickson, G., and LaSalle, J."Human Resources for MIS: A report ofResearch," MISRC-WP-O 74-01, Universityof Minnesota, Minneapolis, Minnesota,May 1974.

[19] King, W.R. "Methodological Optimality inOR," in Feedback, OMEGA, Volume 4,Number 1, February 1976, pp. 9-12.

[20] Kintisch, R.S. and Weisbrod, M. "GettingComputer People and Users to UnderstandEach Other," SAM Advanced ManagementJournal, Volume 42, Number 2, Spring1977, pp. 4-14.

[21} Lucas, H.C., Jr. Why Information SystemsFail, New York, New York, ColumbiaUniversity Press, 1975.

[22] Lucas, H.C., Jr. The Analysis, Design, andImplementation of Information Systems,"McGraw-Hill Book Co., New York, NewYork, 1976.

{23] Lundell, E.D., Jr. "DPer’s Need for Socializa-tion Found Very Low," Computerworld,Volume 12, Number 24, June 12, 1978,p. 31.

[24] Manley, J.H. "Implementation Attitudes: AModel and Measurement Methodology," in



Schultz, R. and Slevin, D., eds., Implement-ing Operations Research~ManagementScience, American Elsevier PublishingCompany, New York, New York, 1975.

[25] Moskowitz, H., Schaeger R.E., andBorcherding, K. "’Irrationality’ ofManagerial Judgments: Implications forInformation Systems," OMEGA, Volume 4,Number 2, April 1976, pp. 125-140.

{26] Mumford, E. "Designing Systems for JobSatisfaction," OMEGA, Volume 1, Number4, August 1973, pp. 493-498.

[27] Nolan, R.L. "Managing the Crises inDataprocessing," Harvard BusinessReview, Volume 56, Number 2, March-April 1979, pp. 115-126.

[28] Richards, M.D. "Some Research Needs inMIS," in Smith, R.D., ed., ManagementInformation Systems for the 19 70’s,Center for Business and EconomicResearch, Kent, Ohio, 1970.

[29] Schonberger, R.J. "MIS Design: A Con-tingency Approach," MIS Quarterly,Volume 4, Number 1, March 1980,pp. 13-20.

[30] Senn, J.A. "A Management View ofSystems Analysts: Failures and Shortcom-ings," MIS Quarterly, Volume 2, Number 3,September 1978, pp. 25-42.

[31] Stone, J. and Mason, I. "Too Much JargonHurts DPer’s Credibility," Computerworld,Volume 12, Number 10, March 6, 1978,p. 23.

[32] Wall Street Journal, "Labor Letter: Com-puter Managers Require More Status andResponsibility at Many Concerns," March3, 1981, p. 1.

[33] Werner, R. "The Business Systems Profes-sional," MIS Quarterly, Volume 3, Number1, March 1979, pp. 65-66.

About the Authors

Kate M. Kaiser is an Assistant Professor of MIS atthe University of Wisconsin-Milwaukee. Shereceived a B.A. and an M.B.A. from Kent StateUniversity, and a Ph.D. in MIS at the University ofPittsburgh. Prior to joining the faculty at UWM shewas a member of the Faculty of Management atMcGill University in Montreal. Her researchinterests are career paths of systems profes-sionals, the behavior of project teams during thesystems development process, and personafitycharacteristics of systems designers.

William R. King is Professor of BusinessAdministration in the Graduate School of Businessof the University of Pittsburgh. He is the author ofa dozen books and more than 100 papers in thefields of management science, MIS, and strategicplanning. He is listed in the current editions ofWho’s Who in the World, Who’s Who in America,and other standard biographical references.


Documents

The Manager-Analyst Interface in Systems Development