Customer-developer links in software developmentseng321/lectures/L15-Customer-Developer... · Common types of projects Terms for software consumer Common measures of success Custom

Many of the best ideas for newproducts and productimprovements come fromthe customer or end user ofthe product [15]. In thesoftware arena, tapping intothis source of informationrequires the establishment

of one or more customer-developer links. These links aredefined as the techniques and/or channels that allowcustomers1 and developers2 to exchange information.

Today, a number of factors have combined tomake a wide variety of links available tosoftware developers. Technologicaladvances and cost reductions inthe area of telecommunicationshave brought about the wide-spread use of telephone sup-port lines and electronic mail.At the same time, the creation ofalternative approaches for require-

ments determination have led to widespread use ofprototyping and facilitated teams. Finally, commer-cialization of software has fostered new structures forcustomer participation through the use of focusgroups, user groups, and trade shows.

The tremendous variety of links that are availabletoday represents both an opportunity and a challengefor software development managers. An opportunityexists in that it has never been easier to obtain inputfrom customers. The challenge is that developmentmanagers are now faced with a bewildering array ofcustomer-developer links from which to choose.

Deciding on the number and type of linksto use is anything but straightfor-

COMMUNICATIONS OF THE ACM May 1995/Vol. 38, No. 5 33

Customer-Developer Linksin Software Development

1We use the term “customer’’ to include“user’’ throughout the rest of the article. See[6] for a discussion of the term “user.’’

2 We use the term “developer’’ to include thevarious individuals who are directly involved with

the design and production of software code.

Mark KeilErran Carmel

Development Dimension

Goal

Typical point at which mostcustomers are identified

Number of customer organizations

Physical distance betweencustomer and developer

Common types of projects

Terms for software consumer

Common measures of success

Custom

Software developed for internaluse (i.e., usually not for sale)

Before development begins

Usually one

Usually small (e.g., customers arein same building as developers)

New system project;“maintenance’’ enhancements

User; end user

Satisfaction; acceptance

Package

Software developed for externaluse (i.e., for sale)

After development ends and theproduct goes to market

Many

Usually large (e.g., customersare thousands of miles fromdevelopers)

New products; new versions(major and minor)

Customer

Sales; market share; goodproduct reviews

ward. In the absence of any information on the num-ber of links to employ or the effectiveness of variouslinks, how is a development manager to decide? Thisarticle begins to address these issues by focusing on thelinks that are currently in use and the experience thatdevelopment managers have had in applying them.

By focusing on links that are currently in use, ourgoal is to draw practical insights concerning the typeand degree of participation that should be used toengage customers in the development process [8]. Wedo this by comparing and contrasting the links that areused in two very different environments—the packagedevelopment environment (in which software is devel-oped as a product for external sale) and the customenvironment (in which software is either developed in-house or under contract and is intended for internaluse). Table 1, which is partially based on Grudin’s [6]observations, highlights some of the key differencesbetween these two development environments (alsosee [3] for a related comparison). Given these differ-ences, one would expect to find differences in the linksthat are used across the two environments.

We purposely chose to investigate these two very dif-ferent environments for three reasons: (1) to obtainthe broadest possible view of the links that are in usetoday, (2) to understand more about how managersobtained customer input in the two environments andthe extent to which their environments shaped theirperceptions and choices of links, and (3) to draw atten-tion to links that are currently used in one environ-ment that might be usefully transferred to the other.

BackgroundIt has long been recognized that customer-developermutual understanding and user participation areimportant factors in the successful development andimplementation of systems [4, 8]. Prominentapproaches for encouraging customer participationinclude sociotechnical systems theory (STS) and par-ticipatory design (PD) [1, 11, 12]. Thus, the issue thatsoftware development managers must grapple with isnot whether customers should participate in the devel-opment process, but how they should participate [10].

The literature on customer participation hasdeveloped along two conceptual levels. The macrolevel acknowledges that user participation is benefi-cial (e.g., [7]) and provides general approaches forachieving this objective (e.g., PD and STS). Themicro level focuses on specific requirements analysistechniques. A wide variety of specific techniques(such as those documented in [2]) now exist to aid inthe process of determining customer requirements.What the existing literature misses is the middleground that exists between these two levels, wheremanagers are faced with the dilemma of choosing acombination of links that can be used to exchangeinformation with their customers.

Therefore, our focus is not on specific require-ments analysis techniques per se, but rather on thecombinations of techniques and communicationchannels that are used in practice to establish link-ages between customers and developers. The termcustomer-developer links is used here to describe the

34 May 1995/Vol. 38, No. 5 COMMUNICATIONS OF THE ACM

Requirements Gathering

Table 1. Relevant Differences Between the Custom and Package Development Environments

Link

Facilitated team

MIS intermediary

Support line

Survey

User-interfaceprototyping

Requirementsprototyping

Interview

Testing

Email/bulletin board

Usability lab

Observational study

Marketing and sales

User group

Trade show

Focus group

Description

A facilitated, structured workshop with customers(e.g., JAD) that is typically used to elicit requirements.

One who defines corporate customers’ goals and needsto designers and developers.

The unit that helps customers with day-to-day problems (alsoknown as customer support, technical support, help desk).

Textual surveys administered to a sample of customers.

Customers are exposed to a demo, or early version,to uncover user-interface issues.

Customers are exposed to a demo, or early version todiscover system requirements.

One-on-one with end-user; open-ended or semi-structured.

New requirements and feedback stemming from testing.Does not include bug detection.

Customers post problems, questions, and suggestions to abulletin board or through email.

Specially constructed labs for taping and measuring usersubjects at work.

Customers are followed for an extended period to learnwhat they do (e.g., ethnographic, protocol analysis).

Representatives regularly meet customers (current andpotential) to listen to suggestions and needs.

Customer groups convene periodically to discusssoftware usage and improvements.

Customers are exposed to mock-up or prototype andasked for feedback at a trade show.

A small group of customers and a moderator are broughttogether to discuss the software. Discussion is

loosely structured.

Commonly used in:P=Package C=Custom

C

C

P/C

P/C

P/C

P/C

P/C

P/C

P/C

P/C

P/C

P

P

P

P


Table 2. Customer-Developer Links

many ways in which customers and developersexchange information during the developmentprocess (similar to [13]).3

A link inventory of the commonly used customer-developer links was created based on the knowledgeand experience of the authors coupled with a searchof the information systems and marketing literaturepertaining to customer involvement, requirementsdetermination, and product innovation. Based onthese sources and from validation that occurred dur-ing the study, the list is believed to be fairly compre-hensive. Table 2 presents the customer-developerlinks that were included in the study, along with anindication (based on our own experience) of theenvironment(s) (i.e., package, custom, or both) withwhich the link is normally associated.

The customer-developer link inventory (of Table2) is the foundation for a central concept of this arti-cle, namely, that these links can be counted within agiven project. The notion of counting links has intu-itive appeal because it is widely believed that greatercustomer participation can lead to more successfulsoftware projects. Additionally, from the literature onemployee participation in the workplace, we knowthat participation is most effective when a combina-tion of different approaches are used to involve work-ers [9]. Thus, we argue that defining and countinglinks is an important first step toward quantifying thedomain of customer participation. We emphasize,however, that the absolute number of links is only apartial measure of customer participation andinvolvement—the link characteristics and how thelink is employed in practice (e.g., how well the infor-mation is conveyed) may well be more important. Aswith any metric, counting links is but a partial mea-sure and cannot tell the entire story.

Therefore, we augment the link inventory by intro-ducing an important classification—that of direct linksversus indirect links. From a communication perspec-tive, direct contact between customer and developeris preferable to indirect contact because it decreasesfiltering or distortion that may occur. Furthermore,media richness theory [5] suggests that direct face-to-face channels offer the prospect of richer communi-cation because of the ability to transmit multiple cues(e.g., physical presence, voice inflection, and bodylanguage). Thus, direct links are likely to be particu-larly important when there are high levels of ambigu-ity, a situation that is especially likely to occur in thecommunication of system requirements.

Indirect links are those in which the customer anddeveloper do not deal directly with one another butcommunicate through intermediaries or customer



Table 3. Overview of the Sample

P=PackageC=Custom

C1

C2

C3

C4

C5

C6

P1

P2

P3

P4

P5

P6

P7

P8

P9

P10

P11

Description

Telecommunications company(listed in Business Week 1000)

Large computer company (listedin Business Week 1000)

Major airline (listed in BusinessWeek 1000)

Major hotel chain (listed inBusiness Week 1000)

Medium-size beverage producer

Large manufacturer of electricalproducts

Fast-growing software tooldeveloper

CASE tool developer

Fast-growing programmingenvironment developer

Small, successful programmingenvironment developer

Well-known producer of Unix tools

Software division of large hardwarevendor—develops office software

Graphics software developer

Established financial softwaredeveloper (listed in SoftwareMagazine 100)

Established manufacturingsoftware developer (listed inSoftware Magazine 100)

Established office automationdeveloper (listed in SoftwareMagazine 100)

Software division of largehardware vendor—developsfinancial software

3 Customer-developer link connotes both a channel (i.e., a medium for com-munication) and a technique (i.e., a method for communication). From atheoretical perspective these two dimensions may be separated, but from apractical standpoint we chose not to do this because we found that develop-ment managers themselves do not distinguish between the two dimensions.

surrogates. Intermediaries are entities situatedbetween customers and developers, while customersurrogates are entities that are not true customers butare treated as such for the purposes of gatheringrequirements and feedback. Some links are inherent-ly indirect because they do not typically allow fordirect contact between customers and developers.The marketing and sales link (in which a salespersonserves as an intermediary) is one example of this. Inother cases, the distinction is contextual and dependson how the link is actually employed. User-interfaceprototyping, for example, may be conducted with orwithout the developers being present.

MethodologyOur study followed an inductive, multiple-case studyapproach in which in-depth information was collect-ed on actual software development projects. In 1994we visited 17 companies and collected data about 31different projects. Although the companies selectedrepresent a convenience sample we actively soughtout companies, within each environment, that repre-sent variation along the dimensions of industry, appli-cation area, and company size (Table 3 provides briefdescriptions of each firm). Thus, we believe thatthere are enough companies and enough variance inthe sample to make reasonable inferences about therange of methods that are currently being used toobtain customer input.

At each company, a project or development man-ager was selected as the primary contact for the study.These managers were chosen (over customers) as theprimary subjects because of their ability to comment

on the full range of customer-developer links usedduring the development process.

Each manager was asked to select two projects thathe or she had managed (or been closely involved with)within the past few years. In selecting the projects, themanagers were instructed to pick one project that wasrelatively successful and one project that was relativelyunsuccessful. Since there are many definitions of suc-cess, we left it up to the development manager tochoose both the criteria for success and failure and theproject in each case. This approach served tworesearch objectives. First, it ensured that there wouldbe some variance with respect to the relative success ofthe projects in our sample. Second, it allowed us tosample paired cases in which organizational contextand some of the other factors that might affect thesuccess of a project were effectively controlled.4

The interviews were based on a structured inter-view guide and survey focusing on the 15 different cus-tomer-developer links presented in Table 2. Theinterview guide included a page of definitions describ-ing all of the links. These definitions were discussedwith the respondents during the course of the inter-view thereby increasing the reliability of the survey. Allinterviews were conducted by the authors and eachone lasted approximately two hours. The interviewswere tape-recorded and then later transcribed. Inter-view transcripts were analyzed using a variation of thepattern-matching technique advocated by Yin [16].5


C5Company

Lin

ks

use

d a

s a

Pe

rce

nta

ge

of

all

Po

ssib

le L

ink

s

More successful projects

Less successful projects

80

70

60

50

40

30

20

10

0P1 P2 P3 P5 P8 P9 P10 P11 C1 C2 C3 C4 C6

The total number of links used in each project expressed as a percentage of the total number of links possible.The denominator was normalized for the number of possible links in each category (13 for package development,11 for custom development, as indicated in Table 2). Data were available for 14 paired cases involving a relativelysuccessful and a relatively unsuccessful project at each company (i.e., 28 projects in total).

Note:

Figure 1. Customer-developer links used: More successful projects vs. less successful projects

4 Three of the package firms do not have a “less successful’’ project pairingbecause either the manager could not suggest one even after repeated prob-ing, or because of interviewee time constraints.

Results and LessonsHaving described the basic approach used to collectand analyze the data, we now turn our attention tothe results of the study. We present the results in theform of three lessons for software development man-agers. The first and second lessons are based on twoobservations that held across both environments.That similar findings emerged across such differentenvironments suggests that the lessons are likely to berobust and applicable to a wide range of environ-ments. The third lesson is a speculative one based ondifferences that were observed between the customand package environments.

Lesson #1: The More Links the Better…Up to a PointThe prescription that more links are better is basedon a strong correlation that was observed betweenthe number of links used and the relative success ofthe project, as shown in Figure 1. While correlationdoes not necessarily imply causality, we suggest that

managers should err on the side of providing more,rather than fewer, links whenever possible.

Results of the analysis revealed that in 11 of the 14paired cases, the more successful project involved agreater number of links than the less successful project.The mean number of customer-developer links used in

the 14 successful projects was 5.4 compared to a meanof 3.2 in the 14 less successful projects. This differencewas found to be statistically significant in a paired t-test(p<0.01). Additionally, a separate paired t-test for bothpackage and custom projects revealed that the samepattern held across each environment (p<0.10).

The interviews with development managers offeredcorroborating evidence of a relationship between aproject’s outcome and the number of links that wereused. At the end of some of the interviews, managerswere asked to comment on whether there was anyconnection between the number of links and the rel-ative success of the two projects they had described. Inseveral instances, the managers felt very strongly thatthe dearth of links in the less successful projects was asignificant factor in explaining the less-than-favorableoutcome. In other cases, as one would expect, therewere other reasons offered as to why projects werejudged to be less successful.

Finally, the less successful projects suffered notonly from a low number of links but from a low num-

ber of direct links: 10 of the 14 less successfulprojects involved either zero or just onedirect link between customer and developer.As a result, we speculate that having multipledirect links may be particularly important tothe successful communication of customerrequirements and hence to project success.

Determining How Many Links to Establish. Anintriguing issue that arises from our study isto determine the minimum threshold of linksa project should have and the presumedpoint of diminishing returns. Based on ourdata, we suggest that managers should estab-lish at least four customer-developer links,but that by the time one reaches six to sevenlinks, there is a point of diminishing returns.

First, we examine the lower boundary:since the mean number of links that wereobserved in the less successful projects wasroughly three, one can infer that there may

be a threshold above three associated with the num-ber of links needed to ensure adequate communica-tion between customers and developers. As a roughguideline, managers should probably regard fourlinks as a safe minimum.

Next, we examine the upper boundary. While Les-son #1 states that more is better, the law of diminish-ing marginal returns suggests that having too manylinks may be sub-optimal. While each new link addsmore information, the marginal value of that infor-mation drops off as the developers become moreaware of the customers’ requirements (see Figure 2).Since the value of additional information is intangi-ble, in practice it is not feasible for the manager toquantify the precise point at which marginal benefitsequal marginal costs. Nevertheless, the data obtained



Figure 2. Establishing too many linksmay be sub-optimal

Va

lue

of

ea

ch

ad

dit

ion

al

lin

k,

ind

ep

en

de

nt

of

co

st

Number of Links (n)

5 The package cases and the custom cases were analyzed separately to lookfor within-group patterns. Within each of these groups, the more successfulcases were then separated from the less successful cases and the patternmatching process was continued. Finally, the patterns that were observed inthe package cases and the custom cases were compared to see if there wereany across-group patterns that emerged.

from the projects we studied provide some indicationof when the law of diminishing marginal returns islikely to occur. We observed that even the successfulprojects used a relatively small fraction of the availablelinks. In fact, very few of the 31 projects in our sampleused more than 60% of the possible links that can beused to obtain customer input (see Figure 1). Themore successful projects used an average of 5.6 links(s.d.=1.8, n=17). This suggests that the costs associatedwith implementing additional links may exceed thebenefits, once we reach a half-dozen or so links.

Lesson #2: Reduce Reliance on Indirect Links:Intermediaries and Customer SurrogatesHaving discussed the number of links in Lesson #1,we now turn to an issue concerning the use of directversus indirect links.6 Many of the development man-agers that were interviewed perceived that the prob-lems associated with less successful projects resulted,at least in part, from over-reliance on intermediariesor customer surrogates. It is on this basis that we sug-gest managers reduce their reliance on indirect links,substituting direct links between customers anddevelopers where possible.

There are at least two reasons why intermediariesand surrogates are poor substitutes for direct linksbetween customer and developer. First, intermedi-aries can intentionally or unintentionally filter anddistort messages. Second, intermediaries may nothave a complete understanding of customer needs.The following comment from one of the develop-ment managers illustrates the latter point:

The person who helped us define the requirements was anMIS intermediary who had been involved with the program-ming of [another application on the same hardware] in adifferent area of the business. From a usability/functionali-ty standpoint, the MIS intermediary didn’t have muchknowledge…she wasn’t a very good user [emphasis added]because she didn’t understand the complexities of what theywere asking for.

As Grudin [6] observes, these “go-betweens ormediators often discourage direct developer-usercontact…and are often ineffective conduits,’’ partic-ularly for information involving new requirements. Inthe context of surrogates, Grudin suggests that linkssuch as user groups will be less effective when meet-ings are attended by “buyers rather than users and by


Table 4a. Custom Projects: Mean Rating of Common-ly Used Customer-developer Links for More SuccessfulProjects* (1=very ineffective; 5=very effective)

Customer-developer Link

Facilitated Teams

User-InterfacePrototyping

RequirementsPrototyping

Interviews

Testing

MIS Intermediary

Email/Bulletin Board

MeanRating

5.0

4.0

3.6

3.5

3.0

2.8

2.5

Numberof Projects

4

5

5

4

3

4

3

Table 4b. Packaged Software Projects: Mean Rating ofCommonly Used Customer-developer Links for More Suc-cessful Projects* (1=very ineffective; 5=very effective)

6As mentioned earlier, indirect links are those in which the customer anddeveloper do not deal directly with one another but rather through inter-mediaries or customer surrogates.

*Each link was rated for its effectiveness by the interviewee—measured on a 1–5 scale—in terms of “helping to improve the software product’’ (with 1 beingvery ineffective and 5 being very effective). Data were available for ten successful packaged software projects and six successful custom software projects. Linksthat were used in fewer than three projects were excluded from the analysis in order to minimize distortion in the averages. Nevertheless, the means shouldbe interpreted with caution given the small sample size. The less successful projects were excluded from this analysis because project managers had a ten-dency to downgrade a customer-developer link if it was associated with a less successful project, creating a bias.

Customer-developer Link

Support Line

Interviews

User-Interface Prototyping

User Group

Requirements Prototyping

Testing

Marketing and Sales

Trade Shows

MeanRating

4.3

3.8

3.3

3.3

2.8

2.8

2.8

2.5

Numberof Projects

8

6

3

4

4

6

9

4

marketers rather than developers.’’In the remainder of this section, we present data in

support of Grudin’s observations and offer numerousexamples to illustrate some of the extraordinary num-ber of ways in which indirect links can manifest them-selves in actual practice. Based on this evidence, werecommend that managers become more aware ofdifferences between direct and indirect links and actto increase the relative effort devoted to direct links.

Intermediaries and Surrogates Are Widely Used but PoorlyRated. In both the package and custom environments,development managers spoke of the problems theyhad encountered in relying too heavily on intermedi-aries or customer surrogates. In many cases, the use ofsuch indirect links was viewed as a significant factor inexplaining why projects failed. The following remarkmade by a development manager at C2, a large com-puter company, illustrates this point:

The problem we had was we didn’t go out and survey thepeople in the field, the end users…If we had gone right to theend user and not relied on these intermediaries, I think itwould have made a difference [in the outcome of the project].

Paradoxically, despite the possible problems thatcan result from the use of intermediaries and surro-gates, the results of our study suggest that they are fre-quently relied on in both the package and customenvironments—a finding that is consistent with previ-ous observations made by Grudin [6]. In the customsoftware environment, for example, MIS intermedi-

aries were used in 7 of the 12 projects in the sample,despite, as we will discuss later, the fact that this linkwas rated quite low in terms of helping to improvethe software product (see Table 4a). In the packageenvironment we also found a surprisingly heavyreliance on indirect links. In some cases, elaboratewebs of intermediaries—as many as six layers—wereobserved between customer and developer. Over90% of the projects relied, at least in some way, onthe marketing and sales link for customer input andrequirements; but this link was rated “poor’’ by thedevelopment managers, partially due to the tradi-tional antipathy between the technical and sales func-tions found in many firms.

Intermediaries and Surrogates Can Take Many Forms.The landscape of customer-developer links is litteredwith intermediaries and surrogates who can take manyforms. Eight examples from our data (including casesfrom both the package and custom environments) aredescribed here; three involving intermediaries andfive involving the use of customer surrogates. Whilewe suspect that intermediaries and surrogates cantake forms other than those that are described here,we offer these eight examples as a starting point to aidmanagers in identifying and reducing their relianceon intermediaries and surrogates.

• Systems analysts as intermediaries. At C2, a large com-puter company, the facilitated team (JAD) sessionswere populated by systems analysts rather than actu-al end users. The project manager explained:



Figure 3. Customer-developer link selections: Percentage of all (successful) projects(in each category) that used a particular customer-developer link

Faci

litat

edTe

am MIS

Inte

rmed

iary

Supp

ort L

ine

Surv

eyUs

er-in

terf

ace

prot

otyp

ing

Requ

irem

ents

prot

otyp

ing

Inte

rvie

w

Test

ing

Emai

l/bu

lletin

boar

dUs

abilit

y la

bOb

serv

atio

nal

stud

yM

arke

ting

and

sale

sUs

er g

roup

Trad

e sh

owFo

cus

grou

p

100

90

80

70

60

50

40

30

20

10

0

Custom

Package

Occurrences of customer-developer links presented as a percentage of the projects for each category (package and custom; n = 11 and n = 6, respectively).

Note:

Instead of bringing all the users to a JAD session, systemsanalysts were sent out to the field so that they could come backand represent a cross-section of the users. That’s basically theway [our company] runs. I don’t think in my career at [C2]I’ve ever dealt directly with the end user. There’s alwaysbeen some type of intermediary [emphasis added]. If it weremy decision, I would have gone directly to the end users.

The irony in this example is that the project team tookwhat would otherwise serve as a direct link thatencourages rich communication between customerand developer and transformed it into an indirect link.

• Technical support personnel and VARs as intermedi-aries. At P10, an established package developer,there was a reliance on formal channels for estab-lishing links to the customer. The developmentmanager at this firm noted that he relied heavilyon the “distribution chain,’’ made up principallyof value-added resellers (VARs) and the “supportchain,’’ representing the support line link. Thedevelopment manager noted that:

It would be pretty unlikely that we’d go and find a realend user [emphasis added] and ask them what ought to befixed—there are just too many. I just attended a productlaunch the other day and got accosted by a number of cus-tomers who tried to buttonhole me to get their problems fixed.That’s not the formal way.

• Internal consultants as intermediaries. P9, a developerof complex enterprise-wide packages, has, like P10in the preceding example, a formalized set of most-ly indirect links to their customers. In order to sup-port implementation of their complex products, aseparate services division within the company oper-ates much as a consulting firm and bills for its timeaccordingly. The development manager explained:

When it comes down to design work, we really considerour consultants as users, because they have much more con-tact with our users than developers themselves would.

• External consultants as surrogates. At C4, a majorhotel chain, a less successful project involved thedevelopment of a new conference managementsystem. The system was designed to support thecompany’s worldwide conference involving all ofthe company’s franchisees. The problem was thatthe company had never managed the conferencein-house; they had always contracted with an out-side company that handled all of the conferencemanagement tasks. As a result, the employee whowas designated to run the conference in-house—and who would ultimately use the system—had lit-tle or no experience in managing the conference.This meant that the developers had to get the sys-tem requirements from the consultant who had

managed the conference in previous years. Thenet result was a system that did not satisfy the cus-tomer. As the development manager recalled:

[The consultant] served as a surrogate user in all ourmeetings. [The person] who would become the end user of oursystem was at most of the meetings but she was kind of uselessto us in terms of giving us requirements because the yearbefore she had just done whatever this guy had told her to do.

• Non-representative customers as surrogates. At C3, amajor airline, a less successful project involvedthe development of a new system to support tick-et and gate agents. In determining the require-ments for the new system, the project teamfocused exclusively on international agents, eventhough they knew that the system would eventual-ly be used by both domestic and internationalagents. Unfortunately, the international agentsserved as poor surrogates for the much largerpopulation of domestic agents that the system wasalso supposed to support.• Supervisors as surrogates. This may be the mostcommon mistake in the custom environment. Weoffer two examples. At C6, a large manufacturerof electrical products, a less successful projectinvolved a customer support system that facilitat-ed the centralization of distribution facilities. Inthis case, the developers were instructed by man-agement to gather requirements only from distri-bution center supervisors rather than the workerswho would actually be using the new informationsystem. Ultimately, this decision meant that therequirements were never adequately assessedeven though the development team emphasizedthe use of what would normally be seen as aneffective direct link, namely facilitated team meet-ings. The development manager explained:

We had union issues to deal with. We were actually shut-ting down shipping facilities and consolidating them intoone distribution center. Plants were losing certain jobs. It wasall very hush hush…a secretive project. So the core group [ofsupervisors] that continued to meet was instructed to keep thisunder their hat and not to let it out [to the workers]. Unfor-tunately, we never involved the people who would be usingthe system. They were not aware of the project and there wasno ability for them to come back and say: “Hey, you haven’tthought about this or that.’’ It was shoved down their throats.

At another company, the project manager explainedthat a less successful project “got into trouble’’because individuals who had been elevated to staffpositions were interviewed instead of actual end users:

The [surrogates] were people who used to be [in the field]and had now moved into a staff position …They were sup-posed to represent the needs of the users to the developers. The


thing that’s a little bit concerning about this is that some ofthese people were three to five years removed from that function.

• Marketing personnel as surrogates. At P11, a soft-ware division of a major computer hardware com-pany, the marketing staff insisted that they knewthe customer requirements and demanded thatthe developers obtain the requirements fromthem rather than directly from the customers.The development manager explained:

Our program management [marketing] people driveproduct development and they said: “We’ll define the prod-uct for you.’’ These are marketing people who have been inthe ranks for a number of years, believing they know theproduct and understand customer requirements. They basi-cally said: “Here are your requirements—build a product.’’It was a dismal failure.

There was little or no customer involvement up front. Itold them [marketing] it was the wrong way to go and thatit was not meeting the primary objectives of the program. Theresponse was: “Then we’ll change the objectives.’’ The mar-keting pressures were so great for this application that itforced us to do the wrong things. I don’t think they [market-ing] understood what the product should be.

• Developers as surrogates. P4, a small company thatproduces software tools, developed a design phi-losophy that can be stated as follows: since thedevelopers themselves routinely use the tools thatthey sell, they are their own customers. There-fore, the developers relied on themselves as surro-gate users. The development manager explained:

The business of eliciting requirements from customers isvery difficult. If the [requirements] are your own require-ments, it’s a lot easier. Your understanding outruns that ofyour customer. Eliciting requirements was straightforwardbecause we were our own customers.

The preceding examples highlight some of themany forms that intermediaries and customer surro-gates can take and suggest some of the problems thatcan result from relying too heavily on indirect links.

Lesson #3: Consider Links Not TraditionallyUsed in Your EnvironmentLesson #3 is based on differences that wereobserved between the package and custom environ-ments in the types of links most commonly used andin managers’ perceptions of which links were mosteffective.7 Specifically, our data suggest that the twoenvironments not only rely on different links but

that some of the links perceived to be most effectiveare used almost exclusively in one environment andnot the other. We first present differences betweenthe two environments and then offer a set of inter-pretations as to why these differences exist andwhat implications they hold for development man-agers. Based on the data, we suggest that develop-ment managers in each of the two environments westudied should consider using links not traditional-ly used in their environment but which are per-ceived to be particularly effective.

Differences in the Types of Links Selected. Figure 3 showsa distinct difference in the use of particular linksacross the two development environments (as sug-gested by the “P’’ or “C’’ classification of Table 2). Inthe custom software environment, prototyping (bothfor requirements and for user interface), facilitatedteams, interviews, and MIS intermediaries were allused quite commonly, appearing in more than two-thirds of the custom projects. In the packaged soft-ware environment, marketing and sales and supportline were the most commonly used links between cus-tomers and developers. A number of links were usedin both types of project environments. For example,some form of prototyping (either for requirementsor for user interface) was used in more than two-thirds of both the package and custom projects. Inter-views and testing links were also commonly used inboth environments.

Differences in Perception of Link Effectiveness. In additionto the differences in link selection between the pack-age and custom environments, there were also signifi-cant differences in perceptions of link effectiveness, asshown in Tables 4a and 4b. For the custom projectsthe two highest-rated customer-developer links werefacilitated teams and user-interface prototyping.These were the only links that received a mean ratingof 4 or higher. For the packaged software projects, thetwo highest-rated customer-developer links were sup-port line and interviews, with the former being theonly link that received a mean rating of 4 or higher.

Most interesting, perhaps, is that in each environ-ment there is a “favorite’’ link that is hardly, if ever,used in the other environment. The highest ratedcustomer-developer link for custom developmentprojects—facilitated teams—is not used by packagedevelopers at all. Similarly, the highest rated cus-tomer-developer link for packaged software pro-jects—support lines—was seldom used for customprojects.

It is particularly interesting to note that in the cus-tom environment, the four links rated most effectiveare all direct links. This was not true for the packageenvironment, where two of the four links rated mosteffective were indirect links, namely support linesand user groups.



7Interestingly, there was no statistically significant difference in the absolutenumber of links used in package vs. custom software projects; the meannumber of customer-developer links used in the successful packaged soft-ware projects was 5.7 as compared with a mean of 5.3 for the successful cus-tom software projects.

Explaining the Differences Between the Two Environ-ments. We suspect that the differences in link selec-tion and perceived effectiveness can be largelyattributed to structural differences in the two envi-ronments. Indeed, given the characteristics of thecustom environment noted in Table 1 (e.g., relative-ly small number of customers that are often co-locat-ed with the developers, and who can be identifiedbefore development actually begins), it is not sur-prising that a link such as facilitated teams can beused effectively.

By the same logic, it should come as no surprisethat the support line link was the second most com-monly occurring link in the package environmentand the one rated highest (in effectiveness) by devel-opment managers in this environment. This is con-sistent with previous studies [13, 14] andunderscores the important role that support linesare believed to play in the development of packagedsoftware. As noted earlier, development managers inthe package environment are often confronted witha much larger and more geographically dispersedcustomer base, sometimes making it impossible toidentify customers in advance of development. Thesupport line provides a cost-effective way of reachingsuch a customer base.

The differences in link selectionlead us to the question of what isthe implicit strategic objective oflink selection. Can these differ-ences in link selection beexplained, as we have done, pre-dominantly by the dispersed ver-sus co-located customer base?

We posit that there is another explanation—thatwhat we observed is a case of market fit. Packagefirms fit their customer-developer links to supportongoing enhancements to existing products (newreleases) since their objective is to extend theirproduct life-cycle by constantly upgrading andadding more functionality. At the same time, infor-mation systems organizations developing customapplications tune their links for initial developmentwith comparatively little emphasis placed on devel-oping an ongoing relationship with customers. Thismay be a legacy of the separation between new sys-tem development and so-called maintenance. Thevery term maintenance is misleading, yet it may sig-nal an important distinction that exists between thepackage and the custom environment with respectto ongoing enhancement to existing software andthe corresponding need to establish links to sup-port this activity.

The findings for package link selection present aparadox that begs another question: How do pack-aged software organizations successfully use supportlines—which might otherwise be viewed as a less

desirable indirect link—as a principal conduit forinformation? We offer two explanations. First, directlinks may not be as necessary for conveying infor-mation associated with enhancements to existingproducts, an area of great concern for packagedsoftware developers.

Second, and more interestingly, we believe thatthe answer lies in what we observed about how thesefirms have elevated the status and relationship ofsupport personnel vis-a-vis development personnel.Many of the development managers in our samplespoke of their significant investment in support linepersonnel, the high levels of trust they had in them,their knowledge of the products, and in their abilityto collect customer input. For example, at both P1and P3 (both packaged tool developers) the supportpersonnel maintained very close continuous contactwith the developers and were viewed by the devel-opment managers as an extension of the develop-ment team.

Implications for Development Managers. Given the dif-ferences observed between the two environments,and our interpretation of why those differences exist,we believe the lesson for development managers is tothink broadly in selecting possible customer-devel-oper links. While some links may be specific to a par-ticular environment (e.g., trade shows), there is noreason why other links would not be transferableacross the two environments that were studied.Therefore, we believe that development managerswould do well to consider using links that haveevolved outside of their particular development envi-ronment. Specifically, we recommend that develop-ment managers in the package environmentconsider using various facilitated team techniques asa direct link that may be particularly useful in thedevelopment of new software products or majorenhancements to existing products. Similarly, werecommend that development managers in the cus-tom environment focus more attention on using sup-port lines of various types, as an indirect link tosupport “maintenance’’ of existing software. As canbe learned from the packaged software environ-ment, this strategy involves elevating the status ofthese units and individuals.

ConclusionsTo summarize briefly, the contribution of this studywas to introduce the notion that customer participa-tion in software development requires the selectionof one or more customer-developer links throughwhich information can be exchanged. As an initialstep toward understanding link selection and use, anexploratory study of 31 software development pro-jects was undertaken to determine the perceivedeffectiveness of various links and the extent to whichthey are used in practice.


Three lessons can be drawn based on the resultsof the study. First, using the link metric for customerparticipation, we found that more successful projectsemployed more links than did less successful pro-jects. Hence, the first lesson is that managers shoulderr on the side of providing more links. Second, weobserved an abundance of indirect links amongmany of the projects in our sample. The indirectlinks were visible in the form of intermediariesand/or customer surrogates that manifested them-selves in a variety of different ways. We argue thatindirect links are less desirable to use because ofinformation filtering and distortion that can occur.Consequently, our second lesson calls for reducedreliance on indirect links.

Taken together, the first two lessons underscorethe notion that developers are best served by estab-lishing numerous direct links through which infor-mation can be exchanged between developers andcustomers to enhance their mutual understanding.This exchange of information cannot take placewhen the number of links is small or when the chan-nels are distorted by intermediaries.

The third lesson is based on an examination of thedifferences between the two environments that westudied, custom and packaged software. In each,there was one link that was widely used and highlyrated in one environment, but rarely, if ever, used inthe other environment. Therefore, in a more specu-lative vein we offer a third lesson: namely, that devel-opment managers would do well to consider usinglinks that have evolved outside of their particulardevelopment environment.

Finally, given the intense interest incustomer participation in softwaredevelopment from both practitionersand from researchers, we proposethat the notion of customer-develop-er links is an effective framework forboth. Practitioners can benefit bystepping back and taking stock of the

links that are currently being used in their organiza-tions. These links can be compared against the inven-tory of links presented earlier to identify gaps and toevaluate excessive reliance on indirect links.Researchers, in turn, can use this approach as a firststep toward quantifying the study of user involvementand participation using an objective measure that iscommon across any development organization.

Acknowledgments.The authors wish to acknowledge the helpful commentsprovided by Joey George, Eph McLean, KarenHoltzblatt and the reviewers on earlier drafts of this arti-cle. We also want to thank the many development man-agers who were willing to participate in the research andshare their experiences and insights with us.

References1. Bostrom, R.P., and Heinen, J.S. MIS problems and failures: A

socio-technical perspective—part I: The causes. MIS Q. 1, 3(1977), 17–32.

2. Byrd, T.A., Cossick, K.L., and Zmud, R.W. A synthesis ofresearch on requirements analysis and knowledge acquisitiontechniques. MIS Q. 16, 1 (1992), 117–138.

3. Carmel, E., and Becker, S. A process model for packaged soft-ware development. IEEE Trans. Eng. Manag. 41, 5 (1995).

4. Churchman, C.W., and Schainblatt, A.H. The researcher andthe manager: A dialectic of implementation. Manag. Sci. 11, 4(1965), B69–B87.

5. Daft, R.L., Lengel, R.H., and Trevino, L.K., Message equivocal-ity, media selection, and manager performance: Implicationsfor information systems. MIS Q. 11, 3 (1987), 353–366.

6. Grudin, J. Interactive systems: Bridging the gaps between devel-opers and users. IEEE Comput. 24 (Apr. 1991), 59–69.

7. Hirschheim, R., and Klein, H.K. Realizing emancipatory prin-ciples in information systems development: The case forETHICS. MIS Q. 18, 1 (1994), 83–109.

8. Ives, B., and Olson, M.H., User involvement and MIS success: Areview of research. Manag. Sci. 30, 5 (1984), 586–603.

9. Kochan, T., Cutcher-Gershenfeld, J., and MacDuffie, J.P. Employ-ee Participation, Work Redesign and New Technology: Implications forPublic Policy in the 1990s. Commission on Workforce Quality andLabor Market Efficiency, U.S. Department of Labor, May 1989.

10. Lees, J.D. Successful development of small business informa-tion systems. J. Syst. Manag. 38, 8 (1987), 32–39.

11. Mumford, E., and Henshall, D. A Participative Approach to Com-puter Systems Design. Associated Business Press, London, 1979.

12. Schuler, D., and Namioka, A. Participatory Design: Principles andPractice. Erlbaum, Hillsdale, NJ, 1993.

13. Software Industry 1993 Business Practices Survey. Price Water-house, 1984.

14. von Hellens, L.A. Conditions for Success in the Design andImplementation of Packaged Software: A Study of AccountingSoftware for Small Companies in the United Kingdom. Ph.D dis-sertation, Oxford Institute of Information Management, 1990.

15. Von Hippel, E. Lead users: A source of novel product concepts.Manag. Sci. 32, 7 (1986), 791–805.

16. Yin, R.K. Case Study Research: Design and Methods. Sage, BeverlyHills, CA, 1984.

About the Authors:MARK KEIL is an assistant professor of Computer Information Sys-tems in the College of Business Administration at Georgia StateUniversity. Current research interests include software projectmanagement, user involvement, and implementation issues associ-ated with information systems. Author’s Present Address: CISDepartment, Georgia State University, P.O. Box 4015, Atlanta, GA30302-4015; email: [email protected]

ERRAN CARMEL is an assistant professor at The American Uni-versity in Washington D.C. Current research interests includedevelopment practices in packaged software organizations and theinternational competitive implications of these practices. Author’sPresent Address: Kogod College of Business Administration, TheAmerican University, Washington D.C. 20016-8044; email:[email protected]

Permission to copy without fee all or part of this material is granted provid-ed that the copies are not made or distributed for direct commercial advan-tage, the ACM copyright notice and the title of the publication and its dateappear, and notice is given that copying is by permission of the Associationfor Computing Machinery. To copy otherwise, or to republish, requires a feeand/or specific permission.

©ACM 0002-0782/95/0500 $3.50



C

Documents

Customer-developer links in software developmentseng321/lectures/L15-Customer-Developer... · Common types of projects Terms for software consumer Common measures of success Custom