Achieving Cooperative System Design:
Shifting from a Product to a Process Focus*
Kaj Grønbæk, Jonathan Grudin, Susanne Bødker and Liam Bannon
Computer Science Department, Aarhus University
Ny Munkegade 116, DK-8000 Aarhus C, Denmark
Abstract
This paper discusses issues arising out of efforts to establish cooperation between users and developers in systems development projects. At first glance, many projects seem to present immense obstacles to user involvement. At the same time, there is a growing recognition of the need for greater user-developer cooperation and research projects are providing new tools and techniques that assist in engaging users as full participants in system development. Two projects serve as examples to frame a discussion of the nature of user involvement (or lack of involvement) in development projects. They indicate both the possibilities for, and the obstacles to, user participation. We believe that cooperative design will improve the quality of interactive computer applications. Achieving it requires overcoming serious obstacles. Users need to be involved early in the process and the agreements or contracts governing development need to be re-thought: Inflexibility hinders iterative design, independent of the type of project under consideration. Development contracts should be shaped as process contracts between user and development organizations with scheduled renegotiation points. We believe that the concern for quality products and processes requires that systems development assume more of a process focus than is currently evident.
1. Introduction
In the first decades of computer system development, most users of computer systems were engineers and programmers, so "user participation" in development was not actively sought—the developers themselves were good user representatives. In the past 15 years this has changed substantially, as computer use has spread to work environments very unlike the engineering environment (Grudin, 1991). The new divisions of responsibility and the divergence of qualifications have widened the gulf between the developer and user environments. This gulf must be bridged and the most direct approach for doing so is to increase user involvement in development.
Cooperative development—full participation by both developers and users—requires rethinking the tools and techniques used in systems development (Greenbaum & Kyng, 1991). Motives for doing this range from simple cost-benefit arguments—early involvement of users with the future system may lead to adjustment of their expectations, making eventual acceptance more likely—to concern for democracy in working life. Our point here is that user involvement is needed to achieve quality: Better products, such as computer applications, will result when the developers have a knowledge about users’ practice and future use situations that can only be obtained through cooperation with users (Bødker, 1991; Ehn, 1988; Ehn & Kyng, 1984). This, in turn, entails focusing on the quality of the development process. Although user involvement may take various forms, we believe that in all such situations the users must be taken seriously—involvement cannot be a matter of knowledge extraction or "adjusting their expectations." It is essential to commit to ensuring benefit for both users and developers.
Good intentions on the part of the developers do not ensure successful cooperation. Structures and processes in a development organization have a large impact on the conditions for user participation. Computer systems development takes place in a wide range of contexts, each with specific advantages and disadvantages for successfully engaging current or potential system users. One commonality is that most development projects are organized around a product to be delivered—they share a "product focus." In this paper, we argue for shifting to a "process focus," wherein a key process element is the enhancement of conditions for user involvement. In the absence of such a shift, individual developers may find themselves engaged in an uphill struggle within their organizations to obtain the user participation needed for project success.
Systems development always occurs within a particular socio-economic system: Projects are partially framed by the rules and practices of the surrounding society. Many countries have legislated that representatives of different interests be involved in projects; elsewhere, management and labor have agreed to consultation over any proposed change in working conditions. In most European countries formal technology agreements between trade unions and employer organizations establish requirements for development processes. For example, Danish employers initiating a large system development project must first obtain the employees’ acceptance of the overall project goals and the expected consequences for work organization. As another example, Danish legislation restricts software products that use databases containing personal information.
Other societal conditions and processes include the availability and qualifications of current and prospective workers and the technology that exists in, or could be acquired by, user and development organizations. General economic conditions are also important; these include customer, supplier, and competitor relationships. Closer to the development project, the structure and processes of development and user organizations can limit or promote the distribution of power and responsibility among different parties (e.g., department managers, individual workers, and unions). As noted by Mathiassen (1981), these conditions are not static, they are changed by organizational and societal processes, possibly including the very development project itself. This is the case, for example, when a development organization hires people with different qualifications or when an application that enables information collection from sensitive databases leads to legislation governing its use.
The interaction of these and other conditions can help or hinder successful cooperation of users and developers. Our discussion focuses on systems development projects that are limited in time and resources. Two case studies of development projects with different contexts and outcomes illustrate typical obstacles and some opportunities for achieving cooperative design processes. The first case is a product development project in an organizational context that inhibits user involvement. The second case starts as a contract development project based on a product specification, but the project undergoes changes that introduce more active user involvement. This case gives an account of cooperative development in a project marked by a rather complex web of contractual relationships. The projects were chosen both to illustrate different possible contexts for establishing cooperative design processes and because the authors had detailed knowledge about the history of the projects. The projects are discussed in terms of the partners involved and the accompanying agreements or commitments.
Following presentation of the two cases, we discuss several issues that affect successful cooperation: 1) the identification and timing of involvement of the parties to a development project, 2) the nature of the contracts or agreements governing development, 3) how a process focus might be more insightful than the more typical product focus.
As an orienting frame, Figure 1 portrays some of the possible partners in a project and their prototypical relationships. This scheme is utilized below in the discussion of our two cases. The outside "box" represents the wider social and political environment in which specific organizational processes, such as system development projects, are embedded. The triangles represent organizations, with overlapping triangles denoting multiple organizations of the same type. The primary relationships between actors are denoted by heavy lines, with bi-directionality implying mutual or reciprocal influence. Dotted lines indicate linkages that are possible but not always present. In fact, the dotted lines represent linkages that we, in this paper, advocate that development projects establish. The ovals represent the actual groups involved in negotiations between and within each organization.
Figure 1: Prototypical partners and relationships in a system development project
2. Case 1: The Advanced Workstation Project
Note: In this first case there was no real user involvement in the development process, other than user testing, which we did not consider as user involvement per se. In our analysis of the project we shall discuss the apparent rationale for this lack of involvement. Many of the apparent obstacles point to a lack of understanding of the rationale behind user participation, as well as to organizational problems in achieving it.
In 1985, a large product development company assembled an elite team of software engineers to develop the company’s first powerful, bit-mapped workstation to support "office automation." This project was unusual in having a relatively free design charter and schedule; most projects were revisions of existing products, implementing, under a tight schedule, changes to the product that had been specified in advance. The system was to support word processing, a spreadsheet, business graphics, time management, electronic mail, and other applications to be specified later. Determination of the precise application mix was part of a marketing strategy decided upon at high levels in the company. The human-computer interface was an important aspect of the project. The development team was to define it for both the system-level functions and the applications, the latter to be written by other groups.
The development team had no prior experience in involving users in the design process, apart from informal discussions with developers and secretaries who used the company’s products. Most projects provided little time for such activities, few means to accomplish them (the nearest large user organizations were many miles away), and little incentive, since the changes to be implemented were specified in advance. This project, however, had both a need and an opportunity to break with that practice. Collaboration with prospective users could have benefited the decision between using a proprietary or a commercially available operating system, as well as the design of the graphical interface (new and not well understood at the time). This project had substantial time and resources, but the concept of such collaboration was unfamiliar and was simply never considered. Let us analyze the structures and processes found in this case more closely.
Figure 2: Project partners and their relationships in the Advanced Workstation project (Case 1).
Structure
An outline of the relationships among some of the groups involved in the project is shown in Figure 2. On the left are represented relationships among groups within the product development organization. The arrows from groups in the development organization to groups in user organizations represent commitments related to users of existing products. Similar commitments would be expected to develop for the Advanced Workstation following its release. The software engineering group was the hub of activities on this project, not surprisingly. A User Group consisting of representatives of major purchasers of the company’s products is represented by the dotted oval on the right.
In recognition of the importance of usability, a "User Interface Group" of software engineers was established. They were to define the human-computer interface and write much of the code to support it—the window handler, menu handler, message handler and so forth. An early priority was to write a "Users’ Manual" as a preliminary design specification. A room was reserved and equipped for experiments with prototype use. Recognizing the interlocking aspects of the software, documentation, and training, they obtained two technical writers from the Publications Department, provided space for two performance analysts, and hired someone to design the training and form a bridge to the Training Department. The marketing representative overseeing the project attended meetings from the start. One member of the User Interface Group was assigned to be liaison to the corporate Human Factors group; he also began working to bring in graphic design expertise from industrial design.
The core project development team had only a very general sense of the future users—office workers. Responsibility for thinking about users was sharply divided: Management considered the strategic market segment to pursue; marketing focused on application-level functionality; the development team was responsible for the system’s "look and feel"; and support groups were responsible for documentation, training, and other aspects of the system. In fact, the preliminary "Users’ Manual" was actually used to communicate the interface design among these groups and was never reviewed by actual office workers.
Process
This project organization did not survive organizational pressure. The technical writers felt their career paths were jeopardized by their separation from the Publications Department and returned to it, assuming a more distant involvement in the project. The training developer found that senior people in the geographically distant Training Department were unwilling to yield the overall design of training to her and eventually she also left. The performance analysts produced a list of operations and minimum response time requirements for the product based on "rules of thumb" that the developers found unmotivated and difficult to translate into meaningful design constraints; the performance analysts soon stopped attending meetings. The effort to involve graphic design specialists in designing displays and icons took a full year, due to the need to educate them about the system goals and features and to overcome the resistance of some software engineers, who while inexperienced had grown fond of their own designs. The principal marketing representative focused on the application set; marketing input on other issues was sporadic, based on encounters with design specifications—for example, a previously uninvolved person from International Marketing appeared and demanded that features be changed. The Human Factors group carried out experiments on input device design, windowing techniques, cursor control keys, and other aspects of the system, using internal employees (secretaries or developers) as test subjects for user testing. Their data sometimes helped resolve ongoing arguments, but typically were perceived to cover too little and arrive too late. As developers grew increasingly loathe to "throw away code," a separate prototyping group was established. This worked well until project resources had to be cut back, at which point this group was drafted into development and the prototyping effort stalled.
Contacts and agreements with external groups were minimal. At various times the project received high-level advice from industry consultants and information system specialists in major corporations by showing them the specifications and by bringing them in for round-table discussions ("focus groups"). At one point, Marketing arranged for several developers to visit clients at a few major customer sites. The developers were astonished at how little the company’s products in use resembled those leaving the development company. Customers did considerable modification, adding software or altering the system software so that most users saw only a fraction of the functions. After over a year of development, the company provided a major client with several "prototype systems" consisting of hardware and the most basic system software, entirely for use by the client’s in-house development groups. During the course of the project, a major Users’ Group meeting was held nearby, but developers were denied permission to attend: Marketing considered it a show for customers.
The project continued for three years before being terminated. Development had produced working prototypes of the system (though not of all applications); the concern seemed to be the lack of a market for the product.
Summary and discussion
As we mentioned at the outset, this project did not really bring prospective users into the development process. Human Factors tested some features on company employees, but we do not consider user testing as being cooperative design nor do we consider it to be real user involvement. To some extent, developers regarded themselves as prospective users, since the company had a policy of using its own systems in the development lab. But the system was not targeted for developers or development environments (for example, a spreadsheet was a key application), so those tested were not representative users in many respects—it was this recognition that shocked the developers who saw the modified systems at customers’ sites. Nevertheless, marketing representatives, human factors engineers, industrial design engineers, technical writers, training developers, and performance analysts often described themselves as spokespeople for the users! In that sense, this project was unusually good at recognizing the need to include these perspectives from the start of the project. Members of these support groups often feel that they become involved on projects too late (Grudin & Poltrock, 1989). In an environment where indirect "users’ spokespeople" often find it difficult to be involved themselves, it is small wonder that no one even contemplates involving actual users.
Would cooperation with potential users have enabled the project to avoid the problems that overtook it? Identifying prospective users is difficult in such a project—which is often given as a reason for not doing so. However, finding a plausible set of users might have provided a useful, common yardstick for the entire project, and we think that finding such users is possible. A group of users representing some aspects of the prospective use practice is a better choice than none (it is better to have some idea about how the application can be used than none). Resources for this project were substantial and could have supported partial salaries for such users for the time they would need to devote to the project. Furthermore, many user organizations, interested in obtaining state-of-the-art experience with technology, are open to cooperation. Not only is it conceivable that such projects could enlist active user cooperation, doing so might result in a happier fate than met this project.
3. Case 2: The School Administration project
In our second case, both users and developers accepted the need for good relations and worked for the establishment of good conditions for cooperative development. The project concerns a long-term (4 year) effort to develop an administrative system for approximately 100 schools. The description is based on two empirical studies (Holk-Lauridsen & Nielsen, 1989; Klujeff, Møller, & Petersen, 1989) and on direct contacts with developers in the software company involved. The system was planned for an estimated 3000 end-users. Again, we begin by describing the project’s structure and processes.
Figure 3: The School Administration Project : Partners and their relationships in (Case 2).
Structure
The system consisted of ten sub-systems to be developed partially in parallel. The system included student administration, building administration, etc. The contract was awarded by the Department of Schools (the customer) to a hardware vendor, who subcontracted the software development. The Department hired a consulting company to manage product testing. Figure 3 provides an overview of the partners and their relationships. The heavy horizontal arrow represents the original fixed-price contract between the customer and the hardware company. The arrow linking the management of the hardware and software companies represents a fixed-price subcontract. The arrow linking the software engineers in the hardware and software companies represents an informal communication path that provided mutual support.
The hardware company (together with the software company as subcontractor) had won the competitive bidding with a system sketch defining the sub-system division. The contract provided for a fixed amount to be paid to the hardware company, which was responsible for selecting the hardware and defining the human-computer interface for the software company. A fixed price ($1.24 million) software contract was also established, some of it directly negotiated between the Department of Schools and the software company.
System developer experience with the technology and the application domains varied. Some had trade school experience, others did not. One developer with experience in the application domain was hired for this project. The software developers incorporated their own ideas about the development process into the plans. For example, they insisted that the contract contain a provision specifying the development of prototypes.
The initial terms of the project contained an agreement specifying the involvement of users and their organizations. The agreement contained provisions for user involvement in design and for subsequent user training. A "managerial-user" group with management level users from six schools was formed and contributed to the overall requirements specification by participating in meetings with the designers. Some managerial users had prior experience with systems development projects. An "end-user" group was established, consisting of representative actual users from the schools. They were to test prototypes and be educated to teach the use of the sub-systems to the large group of users at each site. The "end-user" and "managerial user" groups received economic compensation for their project work: 400 hours of project work annually per person, which roughly corresponded to the amount of time actually spent.
Process
In the beginning, the system developers and the managerial users worked on specifying the requirements for all the sub-systems. This specification process incorporated the use of paper mock-ups of screen images and the development of an initial prototype of the first sub-system. However, when the end-users and the consultants tested the prototype, it was clear that the prototype was incomplete and out of touch with the users’ needs. The consultants and the end-users then demanded more influence on the design as a condition for continuing to participate. At this point the project was in serious trouble: The user representatives would refuse to use a system developed in accordance with the specification and initial prototype. At the same time, the software company claimed that major changes in the specification would require renegotiation of the contract. The customer realized that it was partly its fault that the initial specification did not mesh with the actual work carried out in the user organizations. In order not to lose the initial investment, the customer renegotiated the original product contract with the project group (the negotiation is represented in Figure 3 by the diagonal arrow between the project group and the administrative managers). In these negotiations the software company proposed to establish a process contract, explained below.
Following these negotiations, the project moved forward under a new project model based on a process contract. A new requirements specification was created for each sub-system by a design group typically consisting of two systems developers, one representative from the consulting company, one managerial user and two or three actual users. The sub-systems were developed according to the plan of Figure 4.
Figure 4: Plan for each sub-system
Each design group worked from the initial overall requirements specification to produce a new specification for the specific sub-system. The managerial users evaluated the specification and identified the changes to the initial requirements specification, which would require modification of the contract. Such changes that were considered to be vital were left in the sub-system requirements specification; those felt to be less important were set aside for possible future development. The cost of these changes was considered in reassessing the price. The software company constructed a prototype and users’ guide that covered 80% of the functionality. The adherence of the prototype to the requirements specification and the users’ guide underwent a two-day test by a group consisting of the involved users, some of the Managerial Users, and the consultants. On the basis of this test, the requirements were again modified, prioritized, and the price renegotiated. The software company then constructed the sub-system, which was tested, corrected and finally implemented in the user organization. Thus, the plan included two renegotiations of requirements and price for each sub-system. These prototype evaluation experiences contributed to an incremental development process as the implementation of sub-systems proceeded. End-users participated in the design groups by producing requirements specifications, evaluating changes to them, and testing prototypes.
All of the sub-systems were developed and the four-year project came to a close only 11 weeks later than planned. Starting from the original functional specification, 1800 changes were proposed by the users, extending the functionality of the system by approximately 50%. 350 of the changes were postponed. The total price of the system increased by 50% ($0.6 million), but the users got a usable system to support their work.
Summary and discussion
The initial requirements specification was provided by the customer and refined by systems developers and management-level users. This procedure gave the managerial users considerable opportunity to influence the requirements. However, they did not have a sufficiently detailed knowledge of the actual work carried out by user organizations to specify a usable system. Thus, the prototype of the first sub-system was rejected by the end-users. The rejection led to a renegotiation of the contract, changing it into a contract focusing more on the development process. This led to the creation of design groups with end-user participants applying an iterative prototyping approach. In the design groups, actual end-users assisted the managerial users in revising requirements specifications. This way, users influenced the system design. The managerial users, though, could later remove or postpone certain features for economic reasons. The consultants initially were to participate only by testing prototypes and sub-systems, influencing system development only through reports of errors and missing features. However, when the first sub-system failed, they objected to this process. The success of the end-users and consultants in influencing the structure of the project organization in part because the customer accepted responsibility for problems in the initial faulty, incomplete specification.
The development of later sub-systems ran more smoothly. The heavy reliance in the first requirements specification phase on managerial users, who had a good feeling for the overall system requirements but lacked knowledge of the daily work situation, may explain why testing of the initial prototype resulted in so many suggested changes. For example, paper mock-ups of screen images were made, but not provided to end-users for evaluation. Through subsequent cooperation with actual users, the systems developers overcame this problem and obtained a setting that provided the feedback they needed to develop a good system. In all, 64 (out of 3000) end-users from 32 of the user organizations participated in the design activities and thus contributed actively to the development of the system.
4. Learning from our Cases: Creating better conditions for cooperation
Our two cases demonstrate various problems in establishing proper conditions for involving users in system development. In the first case, we note the following points: The future users were poorly defined, there was no tradition of direct user involvement in design, and responsibility for thinking about the users was divided. In the second case, the initial emphasis on management-level users was a mistake: They lacked sufficient understanding of the actual work processes. The original product contract constituted a barrier to direct end-user influence on the design. In this section we discuss development conditions and possible ways to overcome the barriers to cooperating with users in such projects. Some development contexts may profit by borrowing techniques that evolved more naturally in another context. We will focus the discussion on several issues of particular importance: 1) the identification of users to be involved, 2) the timing of their involvement, 3) the contracts and agreements governing a project, 4) the product focus of most projects.
4.1 Late identification of partners is an obstacle to cooperation
The times at which different potential partners in development are identified—the developers, consultants, and users—is a factor requiring careful consideration in planning for greater user participation in design. The best prospects for a balanced cooperation would logically occur when both developers and users are identified at the outset, as is often true for in-house development projects. For example, a hospital decides that its internal software development group will develop a system connecting nurses and technicians. However, as seen in the outset of Case 2, projects with early identification of both developers and users are not without problems. Choosing representative users is not easy—within a single organization one finds groups with conflicting interests, conflicting perspectives on the organization, and very different possibilities of exercising power over one another (Ehn & Sandberg, 1979; Ehn, 1988). Also, these projects may have few resources to spare. Cooperation can inadvertently antagonize users, especially if they view their own "participation" to be part of a knowledge extraction process that does not help them get influence their working conditions. In some cases, users are asked to contribute information that is subsequently used to de-skill or even eliminate their jobs. Another danger is of diminishing the likelihood of system acceptance by raising users’ expectations unduly. Nevertheless, the early identification of all parties is a favorable condition for cooperation.
The product development environment discussed in Case 1 is quite different. In a "pure" product development situation, the eventual users are not identified until development is complete. The initial product idea does of include some conception of a user population, but specific plans may be closely guarded by management to prevent it from reaching competitors, and the intended or actual use may change along the way. While some market research may precede development, there is little pressure to produce a detailed description of the product’s use context. In fact, a vague description may appear to support the desire to appeal to as large a market as possible. This mind-set of striving for broad appeal runs counter to the idea of relying heavily on a handful of users.
For these reasons, in environments in which the development team is clearly identified but user organizations are not, the product focus creates substantial difficulties for full user participation. Even the support groups that see themselves as user advocates, such as technical writing and human factors, are often denied early involvement, due to the perception that development efforts nearer to completion have more urgent need for their attention. Overcoming these obstacles will require changing the development approach to focus on the process, in order to create conditions for user involvement that do not emerge naturally or easily.
Even with a commitment to user participation, identifying the prospective users and the "team" with which they are to collaborate is not easy in a product development environment. Information about existing and targeted user populations is distributed among people in management, marketing, sales and customer support organizations. The development team is often a distributed group, with members from software, human factors, technical writing, training development and elsewhere involved at various times and with varying degrees of communication. On the positive side, these organizations often have considerable motivation to improve the usefulness and usability of their products, they have the resources to commit to it, and they have large numbers of prospective users. (These favorable and unfavorable conditions are covered in more detail in the chapter by Grudin in this volume.)
The Scandinavian UTOPIA project (Bødker, Ehn, Kammersgaard, Kyng, & Sundblad, 1987; Bødker, Ehn, Romberger, & Sjögren, 1985; Ehn & Kyng, 1984) was a research project that applied techniques more typically used in in-house development projects to the design of a system intended for broader distribution. The typographers selected by the graphical unions to cooperate with the researchers were chosen not because they were likely to become actual users of the system, but due to their professional skills and political interest. The typographers continued working part-time at their newspaper to avoid cooption into the technical team and to obtain feedback from a wider group of typographers. Furthermore, the project used newsletters and seminars to reach additional typographers, journalists, newspaper managers, and researchers. Such approaches might be used in commercial settings to explore the possibilities of specific application areas, narrow or wide, and to provide feedback much earlier than is available through alpha or beta site testing, although sensitivity about disclosing plans may be an inhibiting factor.
A different problem with the timing of involvement arises when development follows competitive bidding. Here, too, we find a natural product focus: the requirement to specify the system to be built. In this case, the customer/user organization is first involved. It may have to define the system without input from the eventual developers, although perhaps with the help of consultants, as in our second case study. The developers may not be able to modify or "break" the contract as part of an interactive design process and may even be discouraged or prohibited from establishing ties to the user organization for reasons of security or for fear of incurring charges of favoritism on subsequent contract bidding. In our second case the initial contract terms were modified substantially due to problems that occurred with the initial product specification, but contractual arrangements are often more inflexible.
For large competitively bid contracts, the motivation and resources to overcome these obstacles may exist. The next section discusses a key element in overcoming the obstacles—the development of more flexible, process-oriented contracts. (The influence of timing of involvement in development on user participation is discussed in more detail in Grudin, 1991.)
4.2 Fixed contracts are obstacles to iterative design
In Case 2, competitive bidding led to a fixed product contract between the development organizations and the customer/user organizations. The contract assumed that the development of the system could be based on an initial specification made by a group of management level users together with the developers, but, as described in section 3, the customer recognized the need for renegotiating this in order not to lose the initial investment. Thus, it was possible to set up a new project model that included price renegotiation, iterative design, and incremental delivery of sub-systems. Since some system feature ideas that emerged from direct user involvement would be expensive to implement, it was agreed to renegotiate the price based on their assessment of in the prototypes. This case suggests that an initially disastrous design proposal can evolve into a successful development project when a fixed contract is replaced with a strategy providing for flexible renegotiation.
The issues raised by fixed contract proposals are too complex to take up fully in this paper. It is an important issue, because changing socio-economic conditions may bring about an increased reliance on this approach to software acquisition. In discussing problems for cooperative system development in contract situations, Gundry (1988) claims that "co-operative system acquisition" is losing ground to competitive purchasing due to the difficulties of controlling money and time with the former policy. He is pessimistic about the possibility for extending the flexibility of contracts and argues for finding a way to fit user concerns into the more restrictive competitive type contracts, although he recognizes the difficulties and limitations in doing so. We do not share his pessimism about more cooperative strategies and more flexible process contracts, having seen encouraging signs within the commercial sector that such contracts can be negotiated successfully.
In general, fixed contracts may hinder iterative design, independent of the type of project considered. Development contracts should be shaped as process contracts between customer and development organizations with scheduled negotiation activities. The contract should outline a set of work tasks which the customer wishes to have improved, together with a set of guidelines or procedures about how, rather than attempt to define the system in advance. Of course, customers prefer the security of having a fixed price/fixed time contract, but the reality is that such contracts often live in fiction. The deliverable is generally a far from adequate simulacrum of the desired item. The potential magnitude of this problem is seen in a U.S. General Accounting Office study of nine software development projects (which were not selected at random, however), where under 5% of the overall expenditure resulted in software that could be used as delivered or with minor changes (Martin, 1988, p.4). Agreeing on a process to take place within a certain frame can easily create equal or better security.
Where possible, contracts might incorporate aspects of the project model that evolved in our second case. Boehm (1988) proposes that in-house development projects incorporate iterative design through cyclic or spiral models that explicitly schedule checkpoints for reconsidering future activity. For contract development projects, he describes experimental approaches for increasing flexibility, including multi-stage contracts in which several developers produce prototypes in the initial round, level-of-effort and award-fee contracts for evolutionary development, and design-to-cost contracts. Project models such as the spiral model seldom define the degree of user involvement, hiding it under the label of phases such as "prototype evaluation" or "test." However, we suggest that more active user involvement, at least to the extent seen in Case 2, is more likely to produce usable interactive systems. Thus, contracts between development and user organizations could also provide explicitly for the use of certain cooperative design techniques (as described in Bødker & Grønbæk, 1989; Greenbaum & Kyng, 1991; Kyng, 1989) to facilitate active user involvement at different stages.
4.3 A product focus is too narrow
Cases 1 and 2 deal with development tasks where the user and development organizations are separate units with no history of cooperation. The projects start out trying to specify the product to be developed. In this sense they are very similar to traditional system development projects that start by attempting a complete product specification, with the inherent assumption that the future users’ needs can be completely analyzed and anticipated. This is a strategy, however, that leads to many products being rejected by users (Bødker, 1991; Ehn, 1988).
Our Cases 1 and 2 diverged from the traditional approach to varying degrees in recognizing a greater need for focusing at the outset on the needs of potential or actual users. Case 1, the workstation development project, provided only a modest change of focus, primarily through greater communication among those responsible for different aspects of the user interface. A more radical shift of focus was seen in Case 2, the school administration project. There, the development project changed from a fixed contract for the delivery of pre-specified software to an evolutionary design process with continual, active user involvement. Time was invested in establishing coordination patterns that would not have formed without explicit attention to the processes and conditions required for successful cooperation. This investment in the process was the main reason for the successful outcome.
There are encouraging signs of a shift away from a simple product focus toward an understanding of the process of system design, development, use, redesign and reuse. Breaking down (or tightly coupling) the development/use distinction requires re-thinking the systems development process and the nature of the commitments involved. A number of voices, from different backgrounds, can be heard in support of this shift.
For example, the designer Chris Jones (1988) criticizes software designers for focusing too much on the use of the completed product. He argues for more attention to the process as an end in itself, not simply a means. Regarding the standard procedure of building to a fixed set of specifications, he notes: "Both parties (designers and clients) have to give up the use of the requirements as a semi-legal basis for control and measurement and agree to work together in the continuous meta-process of evolving the design brief and sharing in the eventual decision as to how the problem is to be seen and solved." Continuing, he notes: "Functions, statements of requirements, are essential but temporary. Without them we cannot begin, but unless we can change them we cannot finish, cannot discover.." Jones concludes with the strong claim that "...[we must] recognize that the ‘right’ requirements are in principle unknowable by users, customers, or designers at the start." This position calls into question the nature of most formal contracts today. Similarly, the consultant Tom Gilb (1990) stresses the need to focus on process, not method or static product. He notes that current development methodologies "...are based on a static product model. They do not adequately consider our work to be a continuous process—derived from the past and being maintained into the future."
Yet another voice in support of this shift, coming from academic software engineering, is that of Floyd (1987). She argues for more emphasis on the process of software development than on the efficiency of the resulting code: "The product-oriented perspective regards software as a product standing on its own, consisting of a set of programs and related defining texts... considers the usage context of the product to be fixed and well understood, thus allowing software requirements to be determined in advance," while the process-oriented perspective "views software in connection with human learning, work and communication, taking place in an evolving world with changing needs... the actual product is perceived as emerging from the totality of interleaved processes of analysis, design, implementation, evaluation and feedback, carried out by different groups of people involved in system development in various roles." This shift in perspective calls into question the separability of development and use and the concept of a "complete" requirements specification. Again, Gilb (1990) admonishes software developers to accept that requirements are always changing and to focus on handling this situation by catching problems early through user involvement in the design and specification phase. He also stresses the need for prototyping and frequent iteration. Taking this view for granted, the negative consequences of obstacles to cooperative design, as exist in many existing development contexts, is apparent. In contexts lacking patterns of cooperation between users and developers, a deliberate effort is required to change the conditions, but there is also a good chance that the effort will pay off.
5. Concluding remarks
We have described some obstacles to cooperative design, i.e. design with active user involvement, which can be found in many types of system development contexts today. Effort and expense are required to find and implement techniques to overcome them—to develop methods and tools, and to change organizational practices and perspectives. We have argued that the concern for quality products and processes is the driving force: To create better computer applications, developers need to be more concerned with the work processes in which the computer systems will eventually be used and with the outcome of these processes. Traditional ways to obtain knowledge about work processes, such as user modelling and system description, have failed (see Bannon & Bødker, 1989; Bødker, 1991). We argue for greater emphasis on user-developer cooperation in the development process. Such cooperation requires early identification of the project partners and flexible contracts. Contracts should focus on creating a development process based on user-developer cooperation rather than on attempts to specify products fully in advance. In addition, many of the costs of providing more usable systems are decreasing—computer processing time, memory, maintenance, and so forth. Thus, both market pressures and concern for the use of technology on behalf of those working with it are leading in the same direction. We have discussed apparent obstacles to these positive changes and some attempts to overcome them. Although these attempts were not uniformly successful, we believe that the approaches, described in this and other chapters of the volume and in Greenbaum and Kyng (1991), show promise for many system development projects. They are the first steps towards a radical re-evaluation of current system development procedures and processes. This re-evaluation will lead to increased emphasis on cooperative design as well as greater emphasis on the process per se.
References
Bannon, L., & Bødker, S. (1991). Beyond the interface: Encountering artifacts in use. In J. Carroll. (Ed.), Designing interaction: Psychological theory at the human-computer interface (pp. 227-253). Hillsdale, NJ: Lawrence Erlbaum Associates.
Ehn, P., & Sandberg, Å. (1979). Företagsstyrning och löntagarmakt. Prisma, Stockholm.
Gilb, T. (1990). Project Management for the 1990s. The American Programmer, 16-30.
Kyng, M. (1989). Designing for a dollar a day. Office: Technology and People, 4, 2, 157-170.
Martin, C. F. (1988). User-centered requirements analysis. Englewood Cliffs, NJ: Prentice Hall.
