Organizational Barriers to Innovation in IT Development and Use
In Hellman, R., Ruohonen, M. & Sorgaard,P. (Eds.) Proceedings of 13th IRIS Conference, Vol. 1 (1990) pp 49-60. Turku, Finland.
Liam J. Bannon and Jonathan Grudin
Dept. of Computer Science
Aarhus University
Denmark
Email: bannon at daimi.dk jgrudin at daimi.dk
June 1990
1. Introduction
In recent years there has been an increased awareness within the information systems community of the difficulties involved in developing and marketing innovative products. Much energy is spent on developing technological inventions, yet we are only beginning to understand, and to enumerate, the complexities involved in successfully shepherding an invention through the numerous bureaucratic hurdles within a development organization before it can "make it" as an innovation in the marketplace. Even when the product has finally reached the market, and can be purchased by the public, there are numerous barriers that must be broken before the innovation is purchased and accepted into the working practices of people and organizations. We still have an impoverished understanding of why certain products "make it" in the marketplace and others, apparently equally innovative and useful, do not. Failures are blamed on many different factors, such as recalcitrant developers, or technophobic users, or poor managerial decision-making, or poor product positioning, but efforts to make a scapegoat of one party are probably misguided. Of course, in some cases one might attribute "blame" in such a simple manner, but we believe that in most cases the reality is more complex, and more interesting, and for that reason, worthy of more detailed study.
To present our argument in a nutshell, we claim that rather than failures being the exceptions that need to be analysed, what is amazing is that any idea ever makes it through the labyrinthine world of conflicting forces within a development organization to become a product that subsequently is acquired and installed by customers. In other words, our claim is that in most cases, organizational and business procedures work against both successful development and use of innovative products. Note that this does not imply that we believe that organizations are irrational; far from it, we would argue that organizations and the groups and individuals that constitute them have multiple, often conflicting perspectives and goals, each with their own internal logic, and that these conflicting concerns existing throughout an organization result in innovations having a difficult time in ever seeing the light of day. Thus we avoid arguments that focus on special factors or the behaviors of individuals in organizations as the cause of problems, and stress the inherent "ordinariness" of resistance to innovation in both development and use environments. Shattering certain myths about why innovations fail can be the first step in re-examining the more routine practices in organizations that result in the production of variants of systems rather than radical innovations.
As this claim may seem overly fanciful, we will present a short story about a hypothetical case of product development and its subsequent introduction into an organization in order to show some of the conflicting forces at work. Although this case is fictional, and for purposes of illustration only, the issues that are raised in it are based on an amalgam of a) our own experiences as developers; b) research on industry practice we have carried out; c) a review of the literature. (See e.g. Grønbæk et al, 1990; Poltrock, 1989.) We only cover a small subset of the potential conflicting organizational goals, in the context of a relatively small and simple innovation in this example, yet hopefully, it is enough to suggest the inherent problems and contradictions in the path of successful innovation.
The paper is organized as follows: Section 2 presents the story of the development process for a piece of software within a small software company, and it is followed by a discussion that highlights some of the key issues that can be identified in the story. Section 3 presents, in the form of overheard conversations in a user organization, a glimpse of life within a "user" organization as the decision to buy or not to buy some new software is made, and it too is followed by a commentary that highlights some interesting points in the user´s dialogue. The paper finishes with some comments about the implications of the viewpoint we elaborate here.
2. The Development Side
A Story......
Niels is a programmer working for RNC, a company that develops PC-based systems for dental offices. Initially RNC was a contract software development house; after developing a system for one dental office, they successfully found other customers for the same software, and are now expanding into foreign markets as well. The systems are primarily used for inventory tracking and billing. Most displays are forms requiring alphanumeric input. Navigation is carried out using function keys and cursor keys -- a interface style that came into prominence in the late 1970s. One day while at his own dentist, Niels hears about a design exercise done by some students to assess the possibility of providing dental assistants with bit-mapped displays to directly record patient information -- for example, by projecting a tooth chart on which the dental assistant can mark areas needing attention. Although the students did not follow up on this project, Niels sees the possibility of integrating such an application into their existing systems and begins to work on the idea in his spare time.
First try
After putting together preliminary design sketches, Niels approaches his supervisor. His supervisor listens, looks briefly at the design, and promises to discuss it with the manager of new product development. Word comes back: the idea has merit, but this is the wrong time. RNC is in the middle of developing EC 1.0, the first version of their system that will cover the entire European Community market. The initial design of EC 1.0 has been complete for some time, and all resources are directed toward completion of the system. So Niels returns his plans to his files, occasionally taking them out and improving them when new thoughts arise.
Second try
RNC completes EC 1.0. Although it relies on fairly standard technology and functionality, it does quite well in the market. Word goes out that planning is beginning for the next version of the product. The window of opportunity has arrived.
Niels is invited to present his plans to the "EC 2.0 Committee," which consists of half a dozen people from marketing, development, and management. Most of them are quite impressed by his presentation, although one vice president says, "this seems a little risky -- Niels doesn’t have firm project completion time estimates, and after all, the company has been doing very well with its character-based administrative systems." The VP concludes, "why not concentrate on expanding our market share in dental administration systems?" Then the marketing representative observes that Niels’s system will be more expensive -- "won’t it make RNC’s character-based displays look antiquated while at the same time being too expensive for our customers?"
The committee is uncertain and moves on to consider a plan proposed by the lead developer of the just-released EC 1.0. This plan consists of minor, incremental improvements in the existing software, mostly adding a few functions that they saw in a competitor’s product. When these new functions are described, Niels’s manager is sceptical. "Are you sure these are useful? They seem like bells and whistles that will confuse the users while offering little advantage." But the Marketing Director backed the lead programmer’s plan. "You don’t understand," he said, "we need those features. Our competition’s marketing campaign makes effective use of their product’s ‘extra capability.’ And besides, we know these features can be built -- after all, they built them." At this point, the lead developer announces that not only is it possible to build it, but they have already prototyped most of the features proposed for EC 2.0 by making quick modifications to the existing EC 1.0 code! And he wheels in his prototype. Of course, the code modifications fall short of what will be needed for a robust, fully-integrated Version 2, but they allow the committee to see and try out many of the new features. This hands-on prototype is very effective.
Niels is given the chance to make one more appeal for his plan. "The technology in our field is changing quickly," he says. "The cost of bit-mapped displays is higher and we are less familiar with developing such systems, but the costs of such systems are declining quickly and we run the risk of falling behind." The committee members look at one another. Then the vice president says, "Niels plan is appealing, but I feel that it is most important that we get out a new release quickly, and here is why." He pulls out a trade magazine clipping and reads it to the group. "‘Ashton-Tate’s decline began with what is becoming a well-worn story in the industry: failure to upgrade a market-leading product. Dbase III Plus went for almost three years before being upgraded, while competitor’s products were upgraded as often as twice in that time. Lyons (an Ashton-Tate executive) responds that he can keep customers by providing predictable if not always exciting upgrades. "Customers don’t want to be embarrassed; they want their investment to be protected. If you are coming out with regular releases, even if they skip a release because a particular feature is missing, they will stay (with the product) because the cost of change is large."’"
Third try: Off the ground at last!
But Niels is not discouraged. He learned something from the meeting -- the value of a working prototype in "selling" one’s design ideas. Unfortunately, those favoring minor improvements had a big advantage over his innovation -- they could prototype by modifying the existing code. But never mind, Niels will be ready next time around. The company has a few Macintoshes and in his lunch hours, Niels works on a prototype of his system. Some of it he programs, while other parts he simulates with Hypercard. When the EC 3.0 Committee is formed a year later, Niels is ready! First he privately brings in key committee members one at a time to show them his system. That way he is able to explore any reservations they have before the meeting and prepare responses. The meeting goes well. The committee endorses Niels plan and directs him to form a team to begin development on Project HyperTeeth 1.0. At the same time, some developers are assigned to make minor upgrades to EC 2.0 -- to create EC 3.0.
The HyperTeeth team decides "we’ll do the right thing." User involvement from the start. Iterative design based on testing of prototypes. They will not be restricted by the old character-based system -- this is the company’s chance to make a clean break. What’s more, they anticipate a huge opportunity for expansion both into East Europe and the American markets. The group is highly motivated and convinced that this will be a landmark, innovative product. Early collaboration with users reveals that they generally like the Macintosh-style graphical interface but that to some it seems a little "toy-like," so the group plans to have a more austere, professional-looking graphic design. This system will innovate in every area!
Third try: Encountering turbulence.
The team distributes the project plan, which includes a sketch of the proposed user interface. They emphasize their commitment to iterative design, stating that features are likely to change as prospective users are consulted. Despite such reassurances, the International Marketing representative seems nervous when he pays a quick visit. "You have to change these icons," he says, pointing to the design sketches. "This one that represents dental charts -- outside of our country, no one has charts that are this shape. Here is a standard graphic representation for dental charts, use it instead. Also, this icon representing "root canal needed" -- that looks an awful lot like an obscene gesture made in a certain part of Tunisia. Maybe you could just use words instead of icons anyway." "Are we going to sell our system in Tunisia?" asks Niels.
Actually this reminds Niels of a problem they are encountering with "user participation" -- how to find "representative users." In fact, getting ANY dental assistant with much time to spend on the project is difficult.
Next they have a problem creating the new graphic design. There is no graphic artist in the company. With resources stretched to cover both EC 3.0 and HyperTeeth 1.0, they don’t have the budget to hire one. The programmers try their hand at designing windows, menus, and icons, but the user feedback they obtain is not encouraging: "Worse than the Mac!" So they decide to "borrow" the Macintosh graphic interface after all, at least for the first version.
Then there is a meeting of all development called by the company president. "I’ve got some good news," he begins. "As you know, Germany is an important market for us, and as you may also know, Germany likes to standardize. They are now working on a DIN Standard for dental office systems, and the good news is that it is based very closely on EC 2.0!" Niels realizes that to meet a standard based on EC 2.0, he will probably have to change some features of his system to be more like EC 2.0. Suddenly Niels isn’t so happy about German reunification!
But the project moves forward. Some users are found. Although less than had been hoped for, their participation leads to improvements on the original design. Some features that had been incorporated from EC 2.0 will have to be changed in order to create a uniform interface to both the old administrative functions and the new features of HyperTeeth. Testing shows that performance is better performance on all tasks with the new design. However, users of the existing system will require a little retraining to learn the new interface.
The day after these design changes are distributed, Niels is visited by the Marketing Director. He is furious. "You can’t change these features from EC 2.0," he shouts. "We have a thousand customers who are already used to the way they work on 2.0. If we tell them they have to retrain, they’ll say ‘If we have to start over, maybe we should start by picking a new company who won’t make us retrain every year!’" Niels is surprised. "These changes are for the better, once people get used to them. And anyway, the HyperTeeth Project is going after big new markets, right? Not just our current customers." "It isn’t that easy," says the Marketing Director. "If we force our existing customers to retrain, they will be upset. RNC will get a reputation for being a company that doesn’t stick with its customers. Once we have that rep you can kiss your new markets goodby! It’s crucial to retain the goodwill of your current customers!" He storms out.
Niels can still hear the echoes of this ultimatum when the Vice President walks in, holding the new design description. To Niels’s relief, he speaks calmly. "Niels, the project is moving along nicely," he begins, but soon he gets around to the new design specification. "You’ve changed the interface design. Again. Where is this going to end up, Niels? Don’t you know that the technical writers are starting to write documentation for the product, the training department is starting to design the training materials, and marketing is starting to position the product? What are they trying to describe? What are they trying to sell? The interface! It disrupts their schedules when you keep changing the design." Niels pauses before replying. "Well, the plan has called all along for iterative design based on feedback from involved users. Unfortunately, the user interface is particularly difficult to design up front. Iterative design is necessary." The VP shakes his head. "Niels, I hear you. But isn’t it a hallmark of software development that careful design precedes development? Adhering to that philosophy has gotten this company where it is today. Redesign late in a project is much more costly than getting it right the first time. I don’t want to see more thrashing on this design, let’s get these "teeth" out there where they can take a big bite out of the competition! You’re doing great! And there is always HyperTeeth 2.0 to look forward to!" After the VP is gone, Niels thinks, "he’s a nice guy. But if only he knew how much software iteration goes on right up until the last moment! But changes down in the software are less noticeable than changes in the interface!"
Despite the VP’s order for no more changes, before the week is over the irate Marketing Director succeeds in protecting his installed customer base by rolling back some of the changes. International also gets their changes. Adjustments are made to meet the DIN standards. One afternoon Niels is leaving a meeting and drops in on his old supervisor, who is now manager of the EC 3.0 project. He invites Niels to have a look at it. The more Niels sees, the wider his eyes get. He had forgotten how much of his original conception had been compromised away. Apart from a few graphical features that his team "borrowed" from the Macintosh, HyperTeeth 1.0 is hardly distinguishable from EC 3.0!
Fourth try
After 18 months, a new product for dental offices that can be run on the Apple Macintosh is announced by the new start-up company formed by Niels to try to recapture his original vision.
Issues in Part 1. Difficulties in successfully innovating in software development organizations.
This scenario portrays many of the obstacles to innovation in a development organization. Of course, the issues are not all one-sided. Existing customers and users in foreign countries do have to be considered, for example. Nor is it necessarily true that such efforts are entirely in vain -- perhaps EC 3.0 (or EC 4.0) will be a little more innovative by virtue of the pioneering efforts of Niels, even if change was not fast enough to satisfy him. And finally, it is always possible that Niels was wrong! Perhaps he was a little too enraptured with the new technology -- it does sometimes happen to engineers! However, the world is changing rapidly, technology is changing, and many systems are bad enough today that major innovation clearly can be a worthy goal. With that in mind, we examine some of the obstacles a really inovative project faces.
Time pressure. The need for timely releases or a tight development schedule may preclude taking the time to develop or test innovative features.
Lack of resources. Even when time is not such a constraint, the design and evaluation skills / resources may not be available. This may lead to "borrowing" existing design features that have had some success in the field.
Prototyping by code modification. In many situations, the easiest approach to rapid-prototyping is to "hack" existing code. This favors minor, incremental changes over major innovation that would require substantial code revision.
Conflict with software engineering practice. Standard software engineering practice has stressed "up-front" design. Practitioners may be uneasy with the number of iterations required to design good interactive systems, as it is difficult to fully anticipate user needs (Boehm, 1988; Poltrock, 1989).
Decision-making by consensus. The need for multiple "sign-offs" on a design makes innovation a target for criticism. Anguished screams tend to make more of an impression than guarded support. This is a particular problem for elements of the human-computer interface or dialogue, as these tend to be very visible, and everybody tends to have an opinion on them.
The power of the installed base. Existing users of a system have invested in learning and adjusting to it, and may reasonably fear shifting to an unproven innovative design. Even a few vocal customers can exert a strong dampening influence on innovation, because developers cannot afford to acquire a reputation of leaving their customers in the lurch.This concern is often amplified by the marketing force themselves who may be uneasy about the effects of major innovations on their own work practices and abilities to provide good customer support.
Standards. Compliance with actual or de facto standards is becoming more important in the industry. The tension between the benefits of innovation and the benefits of standardization tends to swing toward the latter with increasing maturity and use in an area.
2. The Organizational Implementation Side
Once the product reaches the marketplace, there are still many reasons why it might fail, due to certain conservative forces within user organizations. Again, the point to note is that many of these conservative forces have degrees of legitimacy to them, they are not simply arbitrary or idiosyncratic forces. The following story, in 3 short acts, gives us a glimpse into a dental office and the people working there, as they discuss an upgrade of their computing system. After the story, we again pull out some of the forces that affect the adoption of an innovative product , from the viewpoint of a user organization. Although our story concerns a very simple and small organization, this just amplifies the point that we do not have to move to large bureaucratically structured organizations in order to discover factors that may result in resistance to change.
A Story.....
The setting is a small dental office, consisting of 2 dentists and 3 dental assistants who also share various administrative functions in the office. The office currently has a PC-based computer system for handling patient records, and for invoicing.
Dental Assistants: John Dean, Jean Dunlop and Horst Jensen
Dentists : Olav Wagner and Pia Holst
Scene 1. In the Dental Offices of Wagner and Holst.
Jean in background, tidying equipment. John at the terminal, encountering difficulty with keys.
John: Damn! I always get these confounded special function keys confused, why couldn’t they put the name of the bloody function on the top of the key, instead of some silly "PF1" label......who the hell were these guys making the bloody thing in the first place......if I ever get my hands on them!!!!
Jean: Now now John, its not that bad, at least its better than having to type on that old IBM selectric typewriter we used to have to do.....at least we don’t have to repeat so much typing now with the word processing facilities of the system.
John: Yeah, that’s true, but its not much help for actually making the patient records....all these numbers you have to key in......it would be so much nicer if you could have a picture of the guys mouth that you could point to...actually on the screen.......you know, the way a lot of people with these funny looking computers have nowadays...Macs or whatever they call them, you know the ones that have these little boxes with cords on the sides...mice or something.....those guys seem to have more fun doing their work...they don´t have to do so much typing, they can just point to things on the screen, and they can use pictures rather than just text I think.......
Jean: Oh...Apple Macintoshes you mean, yeah I have seen them. One of my friends has one, I have even used it, it´s very easy to use, there are great games you can play on it as well. ......but that gets me thinking....the other day in the dental association newsletter I saw an ad for a new dental administration system using the Macintosh...it also had a screen for the teeth where you could just point and draw right on the diagram for recording fillings and x-rays..that would be neat, wouldn’t it?....it would save us some time in keying in the stuff on the keyboard.
John: Yeah...sounds interesting, maybe you could dig the article up for me...maybe we can try and talk the "powers that be" into having a look at it.....though they are such skinflints....but they do like to show off the latest gadgets to our clients, well Olav does anyway, I have seen him do it....so maybe we could talk Pia and Olav into it, if for nothing else just for the sales impact.....you know, modern, efficient up to date dental office, up to the minute computer facilities etc!!!
Jean: Oh John, you are a lark, but sure, lets look into it, I’ll bring the article in tomorrow.
Scene 2. A Few Days Later in the Office
John and Jean talking with Olav . Horst in background.
Jean: John and I have just been reading about a neat new dental administration system that can be run on the Mac. I know you and Pia have been talking about getting a Mac for some other programmes you wanted, and we were just wondering if maybe you could buy this programme for us to manage our records better. We found another practice that had installed the system. Jack, one of our friends there showed it to us, its really nice, does all the standard book keeping stuff plus has a really nifty graphics facility for keeping teeth records...we were able to get a feel for the system in just a few minutes, and Jack, who has had it for 6 months now says that he is really happy with it, it has a much more natural style to it. Would you be interested in seeing it.?....we could arrange for ......
Olav (interrupting): I don’t know....., I mean we only got the other system a year ago, and it took several weeks for you to get used to it, and it cost us quite a bit....I know that it does not have all the features we would like, but I have heard through the newsletter that a new improved version will be announced shortly, an update that will add some of the features we wanted, so let’s wait for that. I did read that article in the Newsletter about the system, but this company producing it is brand new...that bothers me a bit.... better to stick with a company with a history of reliable product improvement. which is what we have with our current system.
Horst (who has been listening, turns and moves over to the three, showing some impatience): Of course Olav is right, what is wrong with you two? I have spent quite a while learning our system, you know I can do anything with it, its a fine system, if you would only spend the time on learning it like I did. Why go and throw away money on a new system, when the one we have is perfectly adequate...it’s just the likes of you (looking at John and Jean) are too lazy....but you know you can always ask me for help anyway if you need it....
John: Yeah, and watch you utter some total system mumbo-jumbo command....why should we learn that crap....all I hear these days is that computer systems should be "user-friendly"...you know ....I don’t want to be a computer nerd like you Horst.....
Horst: Are you calling me a nerd??
Olav Now now, calm it. Actually it is true that we are thinking of getting a Mac, but I had not thought of using it for this purpose. I still can’t see the sense in getting rid of our current system, but I am curious about what new features it has, you know we have to keep up with the times, show our patients we are the forefront of technology, and all that....it creates a good impression, you know. So, I guess it would be ok to have a look at it if we can get a demo.
Scene 3. A week later
Olav and Pia talking at the end of the day.
Olav: Well, Pia, about that Mac we were proposing to buy...I just the other day saw a demo of this new system for the Mac that John and Jean were talking about, it seemed very nice indeed, I was quite impressed. There are a number of problems about moving to it though, which we need to discuss....though you know I think it would look rather well in the front office, showing how up-to-date we are in this office, as people are getting familiar with seeing computers everywhere.
Pia: I don´t know Olav. Do we really need it? We both had talked about how there will be an upgrade of our older system soon, and it should handle a couple of those annoying bugs in our current version. Also, rather than pushing the technology in front of our clients, I think we should move it further away from them, get more plants, and pictures, make people relax, feel comfortable, away from a whole lot of gadgets and technology, they probably have had enough of that in their work anyway. I think should move the PC away from the front office altogether.
Olav: Hmm, I don´t know about that....maybe.....Certainly John and Jean would like us to get it, though Horst is quite opposed, he can´t see why we should "throw away money" on it, as he says...you know how he treats our system as his baby...he really knows a lot about it....I am a bit worried if we have problems with the new system, who will help us....at the moment Horst won´t touch it he says, and that would be a big problem. I was talking to some other dentists the other night, and some had seen the new system, they thought it was quite good, but seemed to be waiting for others to buy it first before they get it...nobody seems to want to be the guinea-pig.....it´s always the same with new stuff, we are all reluctant to change until someone else does...
Pia: Yes, I understand. I feel that we should not buy it yet, let´s wait and see if others use it. We can manage ok for the moment with the old one, and lets see how well the new version of our system works ..
Olav: Yeah, I guess you are right Pia...
Issues in Part 2. Why it can be difficult to get new ideas/software on-board the organization
Even in a small business, e.g., the dentistry office, a number of issues about technology uptake can emerge, as we see from our story. Here are just a few that can be discerned from the dialogue above.
Workforce problems: Job Roles and Status. Horst has been on staff longer, and has taken the pains to learn the old system X. Due to this expertise, he has greater status, and privileges. These would be infringed by the introduction of a new and "simpler" system, where all might be able to operate the new system equally well, or even be encouraged to do so, by the nice "look-and-feel" of the user interface on the new system...so he has a vested interest in resisting the introduction, or at least delaying it, until he can see how he might be able to use this new system to his advantage There is a lot of literature which shows how dominant interests tend to appropriate new technology to further their own interests ( e.g. Kling, 1980).
Fixed Costs. Managers (dentists) have already sunk money into the old system, and have perhaps paid for training costs for people (Horst ) originally, so they are a bit reluctant to just get rid of the old system. The retraining problem may be much worse when we consider a large company with several hundred users.
Fear of the New. This is not simply a personal psychological issue, - we have little time for the discussions about "technophobia", but rather a rational stance to take about introducing change into an organization, where its effects may be unpredictable. The question is...is it worth it? Is the change really necessary, for the survival of the firm? On a personal level, it can also be argued that people in some settings (e.g. dental offices) prefer more sedate, comfortable surroundings, rather than "hi-tech" environments.
Compatibility with other software/systems. Does the new product mesh with other programs needed in the dental office...can parts of files be moved easily into and out of the application (this can be a serious problem ) ..what about inter-organizational compatibility---what are other dental offices using? This too could be an important issue in many contexts.
Reliability of Manufacturer. Who is making the software?...is there likely to be decent support, training, etc. Many people support the view that "better the devil you know than the devil you don’t". We see this issue emerging in our story.
Track Record of Software. How many packages have been sold? If it is a brand new product are we the de facto guinea pigs for the product? There are many cases where the second developer into an area can correct the mistakes of the first, so buyers are afraid of being burned if it´s too "hot " an item, and often prefer to wait and see what happens. Of course if everyone adopts this stance then the product never gets sold, which is why there is a need for large discounts and inducements from manufacturers in order to try and get people to try out their new product. Without such inducements it can be almost impossible for new products to break into the market, no matter how well designed.
Intraorganizational rivalries. In large organizations, different divisions may want to impose their choices on other divisions. For example, the information systems department may want to control all purchases of equipment in the organization, and not allow individual units the option to buy what they perceive as the best. Often in such cases, the buying will be done according to a long-standing contract with a supplier. This makes it difficult for small scale, innovative companies to get into the picture, despite having a good product.
Conclusion
We hope that.these scenarios provide some feel for the web of often conflicting goals that are found in development and use environments and how they can impede innovation. Although we presented a good number of obstacles in a short space, the typical development project may encounter far more than we have mentioned over the course of many months. More detailed descriptions of some of these conflicts may be found in Grudin (1986, 1990), Grønbæk et al. (1990), and Poltrock (1989).
Although the principal conclusion we have drawn is far from novel, we will repeat it: The best way to see that that useful innovation is nurtured is to be able to demonstrate that it is indeed useful. In the engineering world of constant tradeoff and compromise, a particular position needs to have some powerful backing in order to survive. Today, the most powerful motivation is often the technologist’s enthusiasm for a new piece of technology, and thus the innovation that does survive the conservative forces of development tends to be technology-inspired, not based on the needs of computer users. But if the voices of potential users can be heard in the development process, they can be a powerful force.
Likewise, on the take-up side, often certain technologies are brought into the organization due to the pushings of a particular figure within the organization, a "product champion". It would be a step forward if user groups within the organization could exert more pressure on management decisions to buy products. In both development and use situations, one possible way of increasing user influence on the process of development and procurement is to capture occasions of use of the new product. So, for instance, videotapes of people successfully using an innovative piece of software can help convince the organization of the need to pursue the innovative idea all the way to the marketplace, and in the user organization, videos of employees using the technology successfully and comments by these users can help strengthen the arguments of user representatives for buying specific innovative systems. Without attempting to influence the development or procurement policies, organizations natural tendencies to conservatism will tend to assert themselves, and the likelihood of innovative products being developed and then bought is minimal.
Approaches to bringing such extra "voices" into the process vary. In product development environments it is often done through mediators, such as the marketing representatives described in the scenario. These indirect voices are rarely adequate. Elsewhere, participatory design approaches are being explored as a method of achieving more direct access to future system users (see e.g., Bjerknes, Ehn, and Kyng, 1987; Docherty et al., 1987; Ehn, 1989; Bødker, 1990; Greenbaum and Kyng, 1990). Realizing this goal requires not only new attitudes, but careful attention to changes in the development process itself.
Acknowledgment
Although the scenarios depicted above were entirely fictional, the idea for a system resembling HyperTeeth was borrowed from a participatory design project described in Bødker and Grønbæk (1989).
References