Organizational values and design knowledge integration:
Toward understanding organizational obstacles in software product innovation

Peter H. Jones, Ph.D.
The Graduate School of The Union Institute, Cincinnati, Ohio 

Abstract

Software product design requires intensive knowledge creation, sharing, and integration among members of multidisciplinary teams. Even in highly-coordinated product teams we expect conflict in design decisions, and some argument over the appropriate use of relevant knowledge. We except differences in practice values – yet how well are these differences negotiated? Values and culture are frequently identified in the design literature as an underlying influence of both product concepts and business processes in innovation projects. This study investigated values conflict in large organizational projects to uncover organizational cultural factors impeding innovation project effectiveness in software companies.

Innovation management includes business practices such as project and product management, as well as design management. This research analyzed design and product management practice, across ten case studies of software product teams. The research found significant values conflict in software product design attributed to organizational culture and processes. Values conflicts were related to differences in managing the design process, control of product design direction, coordination of team roles, and to organizational culture issues. Participants attributed conflict sources to design and development processes used by the projects experiencing conflict. These innovation management processes constrained team participation and task coordination, and contributed to requirements conflicts and ineffective resolution of design differences. Therefore conflict arose from reactions to values embedded in standard and supported organizational processes, as revealed in projects that demonstrated significant failures of process.

Cross-case analysis identified four organizational dynamics influencing values conflict. Each dynamic encompasses numerous specific findings from the study that further describe conflict with embedded values in management processes. One, cross-functional projects afford multiple points of conflict with personal and organizational values. Two, business approaches to innovation management afford conflict between professional and organizational norms and values. Three, differences between espoused and in-use innovation processes afforded values conflict. Four, process conflicts interfered with team knowledge integration, affecting the quality of product design and development. Together these four claims offer a framework for understanding and managing design values in innovation projects.

Introduction

Innovation, planning and design processes hold unique positions within organizations. Innovation fulfills the organization’s purpose of serving customers; management strategy sales, service, even accounting align to deliver a desired product. Furthermore, organizational participation in innovation cuts across boundaries. The firm’s entire membership has an interest or some stake in product innovation, and project teams even in traditional companies build membership from across boundaries and functions. In this way the innovation project can be seen as a corporate microcosm.

Corporations maintain their existence and identity by addressing two strategic functions, profit and core ideology. The strategic driver for product innovation is often profit or market growth by various means – new products to increase market share, product return on investment, or improving time to market. Core ideology (Collins and Porras, 1996) relates to the firm’s essential values and purpose – its fundamental reason for being. Products can be evaluated as supporting or diminishing the core values of a firm. For example, when Johnson and Johnson removed Tylenol from store shelves during the 1982 Tylenol contamination crisis, management’s actions demonstrated a clear commitment to the core values of the firm as embodied in their Credo.

Although the relationship between product design and profit seems obvious, the relationship between core values and design is often overlooked. Core values are not always recognized as relevant to software product design decisions, and values choices do not appear as a concern for project managers. However managers in all capacities - design, project, product, or executive - should consider the values issues inherent in product innovation. Many questions reveal uncertainty about intangible values issues. For example, which core values does a product express, and how are they expressed? How do values become embodied in products and how are they perceived? And whose values should be served, the customer’s, the design team’s, or the firm’s?

Embedded design values in software products and practice

This research asserts that values systems embedded in organizational practices shape the design of software products and information systems. However, little current research shows how specific management and design processes embody organizational and personal values. Research has focused on systems that embody organizational and designer values (Friedman, 1997, Kumar and Bjorn-Andersen, 1990), or how organizational structures and processes affect the acceptance and use of systems (Zuboff, 1986, Kling, 1996, Poltrock and Grudin, 1994). Few, if any, studies have analyzed whether values embedded in organizational processes affect the quality of practice or product. The social impact of embedded design decisions in computing infrastructure has been evaluated (Hanseth and Monteiro, 1997, Star and Ruhleder, 1994), but not in product innovation or related business processes.

Large companies share similar cultural characteristics, such as organizational structure and process, management style, market focus, and product development processes. The embeddedness (Baum and Oliver, 1992) of these business practices hides uniqueness and distinctions among their values and operations. Social behaviors are also embedded in the economic and management traditions of organizational cultures and across industries. These embedded organizational behaviors and values in use impact innovation projects through continuous organizational routine, merely by functioning as accepted business and management practice. These routines, as standard organizational and informal design practices, institutionalize constraints on innovation. Organizational groups and individuals then maintain these constraints as part of professional practice and identity.

Embedded organizational values have been reported within advanced processes in high technology. Sachs (1995) showed the predominant work analysis and system development approaches at NYNEX followed values and principles extended from scientific management. Contrasting design approaches in a large-scale project, Sachs distinguished values differences between the “organizational” view and “activity” view of work. The dominant “organizational” model of work held assumptions that designed routine fragmented work, standard tasks and environments, automated routines, and reduced social interaction. These values were embodied in a reengineering approach to system design, resulted in a system (Trouble Ticket System) that reduced effective productivity and diminished skill transfer, due to increased monitoring and control. Sachs study showed impacts on work process and design, suggesting system designers pay attention to the social constitution of the workplace and its practices.

Kumar and Bjorn-Anderson (1990) theorize how methodologies inscribe behaviors within IT organizations, by “incorporating into the design process the ontological assumptions about what constitutes reality.”  Their research traces the values of system designers through their choice of methodology, and suggests values are embedded into the organization through socialization of methodology. They further suggest the values systems embedded by methodology might lead to systems embedding these values, which “may not be acceptable in cultures with value orientations different from the one in which the system was designed” (1990, p. 535).

Software systems and products are designed with explicit and implicit goals and values. Some values and goals originate with the designers, some with producers, and some with purchasers. Clearly not all values are congruent with each other, and in the process of negotiating product requirements and design qualities, these values orientations come into play. Values congruence can be understood as the consistency of a system’s design goals with explicitly stated values - values drawn from the customer’s desired experience or the organizational vision. Congruence or conflict can also be derived by extracting the behaviors and values found in system goals or the interface and specifying the organizational values driving the requirement.

Values congruence and conflict also relate to design evaluation (McDonnell, 1997) in assessing the fit of design alternatives. Alexander (1964) noted the problem described as “misfit” between a designed artifact and the known requirement. McDonnell furthers explains how “what is known to be required refers not only to the problem or need as framed by the designer in explicit terms…” The evaluation for fit also “refers to the demands which are implicit in the designer’s norms and professional practices.” Values misfits may be defined here as incongruence between the designer’s norms and organizational demands. When values misfits occur repeatedly, a systematic organizational influence might be considered.

Social and practice conflicts are revealed in values misfits, ranging from professional differences between workgroups to social differences between divergent organizational cultures. Those experiencing misfits express it through situated interpretation, and not usually as “values conflict.” Few professional standards and methods enable designers to document the impact of values misfits, although Ehn et al (1997) address a similar problem in documenting social impact. These evaluation methods are not yet used as development metrics or even management tools. Therefore, few frameworks for addressing values conflicts in design are currently promoted in academic or design management literature.

This research reveals the social and business impacts of values misfits with innovation practice embedded in organizational processes. It further proposes a framework for evaluating organizational values conflicts, based on empirical findings from software design projects in large product firms. Finally, the research calls for designers and managers alike to understand the influence of embedded values in their practice, and to reveal and choose appropriate values constructs in product innovation management.

Method

The research method adapted case study research for a grounded theory approach (Strauss and Corbin, 1990). A processual research design (Hinings, 1997, Weick, 1993) guided the study from an open-ended, inductive phase to a deductive, theoretical phase. Processual research studies organizational phenomena, specifically issues such as patterns of behavior among groups in context, and understanding organizational behavior. This article reports only on the case analysis findings from a large three-phase research project.

To develop the interview and case analysis instruments, 7 well-known case studies were identified from the literature in information systems and organizational studies. Twenty cases were evaluated and interpreted for their investigation of values in systems and product design, resulting in 7 selected studies. Cross-case analysis was conducted, focusing on values issues in organizational design process, to identify relevant values dimensions for a coding framework and research issues. This analysis developed a model for values research, enabling evaluation of the most appropriate values in the product innovation context. The analysis also supported research direction, by revealing issues missing in the literature.

Semi-structured interviews were conducted with participants meeting requirements based on operational construct sampling (Patton, 1990). Ten participants from 10 different product organizations were split between 5 software developers/designers and 5 product/ business managers.

Participant responses to interview and questionnaire instruments were classified into two values dimensions, personal and process. Personal values were those confronted directly by interactions occurring in the projects. Process values were identified as the values dimensions confronted by organizational and project processes. The transcript text was evaluated for recurring themes, and each instance of conflict was coded as a unique type. Personal values were not coded, but were drawn directly from the transcripts. Values statements were extracted verbatim and within context to preserve a participant’s personal meaning. Process values were captured from a process values questionnaire, completed following each in-depth interview.

Analysis categories were developed from the instruments, drawing from the literature-based case study framework. Open and axial coding (Strauss and Corbin, 1990) specified the categories, using a matrix format. Primary coding factors included team roles, values types, identified conflicts, positive and negative design process values, espoused and practiced organizational values, and product or project impacts.

The 10 cases represented a cross-section of software projects, including Web search and retrieval, CAD-CAM engineering software, retail business management, and legal research software. Products included either innovative (discontinuous) or redesigned products, with the exception of a single infrastructure project supporting a family of products. All product teams sampled were from large organizations, with each containing from 50-300 individuals within the software development group. Team sizes ranged from 6 to 120, with an average of 21 members, with most teams (mode) consisting of about 20 members.

Embedded Values in Innovation Case Studies

The overall study analyzed 10 cases from four source organizations. A large Web-based publishing firm served as the source for 6 cases. Three other participating companies shared a similar institutional context; all were large publicly owned firms with over 1000 employees. Their similarity allows for aggregation of findings and some limited generalization.

From observations and subject description, all cases companies were managed by hierarchical organizations and traditional business processes. Each deployed varying degrees of innovation management, including product, project, design, and development practices. Matrixed cross-functional teams conducted projects in the design and development of new products, but their product managers had no background in innovation practice. Evaluation of organizations and transcripts shows these firms encouraged a strong business orientation toward new product development, and did not support innovative product design approaches.

The cross-case analysis revealed recurring claims of values conflict with project innovation processes. Representations clustered around two dimensions, values (personal vs. organizational) and processes (professional practice vs. organizational routines). Personal values included those disclosed by participants as stable, individually-held values, including honesty, competence, teamwork, openness, and integrity. Organizational values revealed participants’ values associated with behavior in the work context, including customer focus, information sharing, appropriate roles, teamwork, autonomy, and openness. The process dimension was analyzed further through in-depth case study of the two largest participating organizations.

Values conflicts in innovation projects arose from reactions based on personal values to interpersonal or team conflict situations. Individual conflicts with organizational values originated from responses to organizational values in use, which constrained innovation goals or practices, or professional practice behavior. These responses were not found with espoused organizational values, originating from official messages and values statements, management communications, and business management practices. Instead, values conflicts were associated with organizational values in use, as demonstrated in the product innovation practices and related project artifacts used across organizational groups in large firms.

At least one significant conflict was described from every project case analyzed. In all cases except one, participants attributed the conflict to a values difference. Typically, multiple conflicts were identified as having occurred throughout the project. Since the research investigated values interactions in product development organizations, these themes were expected. However, the majority of the claims were represented as organizational process issues, and not specific conflicts with personal values. All four claims reveal systemic components from organizational or development processes, with one claim also identifying conflict between personal and organizational values enabled by organizational process. The key finding of the study was that in nearly all cases, values conflicts were considered embedded in the organization’s innovation processes. The same processes established to manage product design and development were also symptomatic of significant process failure. These failures from innovation process as used ranged from product delays to project cancellation. Although a causal relationship between embedded values and process failure was not attempted in this study, research participants suggested these implications.

Participants overall described 28 unique conflict types across the 10 cases, with all identifying some conflict with the product design process, and 80% describing conflict with control of product design. Four recurrent themes defined the conditions or organizational constraints on innovation practice.

1.   Cross-functional projects afforded multiple points of conflict with personal and organizational values. Coordinating participants from diverse groups in a hierarchical organization increased opportunities for conflict between different professional and organizational groups. Multiple conflicts were found in most cases; conflict was attributed to differences with organizational values and processes. Participants also cited substantial influence from organizational hierarchy and imposed business process.

2.   Innovation management processes (specifically standard project and product management practices) afforded conflict between professional and organizational norms and values. Multiple values conflicts between project team members of different professional practice were evident in each project, and conflicts typically occurred throughout the project. Participants attributed these specific claims of conflict to professional or organizational cultural differences. Intra-team conflicts also occurred as differences in practice used by members reporting to different organizational functions.

3.   Differences between espoused and in-use innovation management processes afforded conflict. Values conflicts emerged when standard innovation practices were neglected, or when alternative practices were used as management interventions.

Standard management processes were published, but followed inconsistently, allowing for high variability of management direction. However, design practices were often contextual and not published or easily visible to managers. Software designers used highly situated practices in designing product features. Therefore, conflict between these two approaches to process showed across the cases.

4.   Process conflicts interfered with team knowledge integration, affecting the quality of product design and development. Projects require design teams to intensively generate and integrate knowledge about the target domain. But knowledge integration was largely obstructed as projects pushed toward execution. Management influence over the design process restricted the time and ability to integrate knowledge into products, even when user data was collected. Teams in these cases also failed to adopt user information supporting requirements, affecting knowledge integration among all team members.

Although values conflict in projects displayed in context as apparently typical project interactions and disagreements, the systemic nature of conflict was revealed by repeated descriptions and attributions to organizational process. Each claim suggests a condition that, by itself, may not result in the type of values conflicts experienced in these organizations. Since all but one participant denoted values conflicts as systemic in organizational process, even across different firms, the phenomenon of embeddedness in process emerged as the most useful approach.

Although other organizational theories can be associated with this phenomenon, such as organizational defenses (Argyris, 1992) and preservation of organizational control in design practice (Poltrock and Grudin, 1994), the values approach revealed fundamental considerations. Together, these four claims explain much of the conflict and intervention found in the case projects. They also support a framework developed from the research for understanding and managing design values in innovation projects.

The following discussion of findings describes the patterns of interaction with organizational values in the design process, with analysis of both effective and unproductive values influencing projects.

Organizational Process Values in Case Projects

Statements were drawn during inquiry about organizational process values revealed in case projects. Process values refer to the participants’ interpretation of values in the 10 projects’ innovation processes. Analysis identified both “supportive” or effective process values and “dissonant” or obstructive behaviors (counter-values). Of 19 unique supportive values noted, the most frequently cited process values were ranked as:

1. Customer focus – Reliance on the customer’s interests and user tasks as product guidance.

2. Information sharing – Transparent sharing of all information relevant to the product or project.

3. Appropriate roles used – Project role’s relationship to team member competencies and interests.

4. Teamwork – Effective team coordination and performance, for both team and role contribution.

5. Independence/Autonomy – Ability to use judgment to adapt professional practice to projects.

6. Openness – Open communication and interpersonal cooperation with team members.

Obstructive process patterns were described throughout interviews, often surfacing more as activity patterns than specific values statements. Whereas participants could identify “teamwork” as a supportive process value, instances of uncooperative team behavior were described throughout the transcript but not necessarily defined as “negative.” Therefore, these process issues were elicited from both the transcripts and the matrix of summarized claims. Across the 10 cases, participants identified the following organizational process patterns in product development by their frequency of citation:

1. Process used as convenient; disregarded otherwise      100 %
2. Blaming individuals for project problems                         70 %
3. Lack of teamwork                                                        70 %
4. Unclear accountability for project results                        60 %
5. Unclear relationship to “customer ownership”                  50 %
6. No defined process - control issues surfaced                  40 %
7. Process was defined but not followed                             40 %
8. Design decisions were arbitrary, no process                   30 %

Clearly there is overlap between these issues; some of these patterns might often co-occur in project activity. Blaming individuals and lack of teamwork would probably correlate highly, and improper use of project authority explains several of these issues (e.g., 1, 6, 8). Although any one of these organizational activity patterns might be found in any successful project, the co-occurrence of, on average, 4 patterns within each project may have contributed to the organizational and market failures experienced by some of the products.

The study made no attempt to further reduce these patterns into an independent set of claims, or to analyze the co-occurrence of patterns conflicting with desired team values. Instead, these findings were used as pointers to deeper process values inherent in the organizational activities in product development.

 Analysis of Organizational Process Values

A post-interview survey collected participant impressions of values in use in their case project organizations. Participants assessed project values against the dimensions generated from the composite values model, as indicated in Table 1. Survey data was consistent overall with the interpretations of values conflicts drawn from the interviews.

The following table summarizes the results of the process survey.

Table 1. Summary of Process Survey Results.

For five of the six dimensions rated, the averages across all projects were within one point of their negative poles. The teamwork dimension was the sole exception, with three cases considered by participants to represent some level of cooperative team behavior.

Even though the interview data presented pictures of typical software projects, describing values conflicts common in knowledge-intensive project work, the strong ratings given these projects overall was surprising. These survey ratings (supported by the case findings) suggest that these values orientations mediated activity to some extent within each project. The survey dimensions are analyzed and supported by excerpts from the transcript, providing a context for these evaluations of project behavior.

Team participation

The average score of 4 suggests participants in the case projects experienced design and development teamwork as non-participatory. Participants interviewed were among the most senior project members, but did not participate fully in design decisions, planning, and project direction, essentially working more as individuals than collaborators. Only one project scored high in participation (2). Review of this high-scoring project showed its senior product manager Paul also believed numerous incidents of communication breakdown occurred during this project, evidencing dysfunctional patterns of team participation even in high-participating projects:

”Some conflict arose because the person who was our main designer was also reporting in to the design group, a different organization - they were setting standards for this class of products while we were developing that product. … we were not in the communications loop to know why things were being done - and it was disconcerting to show up in a meeting and see something that had been changed in the graphical interface without warning from our developers.”

Cooperation

Cooperation focused on effectively interpersonal cooperation on team activity, and probed whether product teams were more cooperative or competitive. The average score of 3.5 showed up as the most positively rated dimension in the survey, suggesting that participants considered their project teams fairly cooperative. The transcripts support this, as they show more conflict between professional groups (designers and managers) and between different authority roles, but few instances of competition for position or power among similar status team members.

Customer-orientation

Perhaps the most surprising finding was that no projects were considered customer-focused. All indicated their projects lacked a focus on actual customer needs, and instead followed internal organizational requirements. In making design decisions affecting the requirements and user interface, management considerations prevailed. In many instances product managers determined all requirements and design decisions without sharing ideas with the project team. However, both professional groups interviewed (managers and designers) believed customer orientation was missing. Both groups also made frequent references to the problem of access to customer data from which to base design decisions.

Management considerations prevailed in these projects even where significant customer data had been gathered for the purpose of informing design decisions. Several projects experienced similar obstacles, as characterized by designer Brian’s statement about the Web Enterprise product manager:

“The value this individual held was that it was … ‘my product and I’ll build the product my way.’ When it came to getting customer feedback, she would ignore the customer feedback if it didn’t agree with her perception, her beliefs. Or she would discount the way the data was collected, like ‘it wasn’t reliable - so I can’t go with that.’”

Product manager Paul (from the Search Buddy project) described how their team actually gathered customer feedback on the product, and then overlooked it when making product decisions in practice.

“I think we probably fell down on getting the customer input. We probably violated some of our principles because we were rejecting some feedback at the later stages. Because by then it was too late, and we were getting a lot of push from our senior manager.”

Task coordination

Task coordination assessed the extent to which project roles were fixed, or allowed to evolve with aptitude or interest. Most projects assigned job roles and held them constant through the project; project management did not leverage skills as they evolved. This was characterized by statements such as product manager Lloyd’s commentary on cultural differences:

“I’ve realized that people like to be told what to do, it’s one of the things that I’ve learned about the American culture. And “go here,” that’s the decision, then everybody goes.”

The Web News project, the exceptional case, scored highly toward the “emergent, based on skill” pole. Product manager Karen’s personal leadership style might have accounted for this score.

“I keep my project management to a minimum - I only do the things I think need to be done to do the project. I don’t like make-work at all. That’s a personal integrity thing - I’m not going to waste other people’s time or my time. I’m not going to have people going to meetings if a meeting is not necessary.”

Requirements conflicts

Product requirements conflicts were resolved by authority rather than consensus, and in nearly all cases by actual management intervention. Team participation was not involved, nor was customer feedback solicited to address differences. In several cases, conflicts over requirements caused maintained animosity between professional groups on the same project team, or between management groups across the organization. These values conflicts were typically related to either professional group differences in the organization or to differences in interpreting value to customers or the business.

Some conflicts with requirements cut across members of the project team, instead of project management. CAD interface designer Mike noted how an engineering team member covertly struck numerous requirements from a project scope list in an attempt to reconfigure a product design and avoid negotiation.

“There was an is/is not list created, from a 400 page requirements document, and probably 400 requirements, and two sections that deal highly with UI, and almost everything was “is not’ed," behind my back, no consultation. You’d just see them show up - luckily, if you looked at the “is-not” list, one day, you’d see that some of your requirements had turned into is-nots.”

Design conflicts resolved

Design conflicts typically occur between designers and product managers, in resolving differences between meeting user needs and business requirements as reflected in the product user interface. In most cases, design conflicts were also resolved by management decision instead of discussion or consensus. The very high average score of 4.5 suggests minimal participation was allowed for settling design conflicts.

Other cases in the transcript show frequent examples of design conflict. As designer Mike noted in the CAD project, team members in conflict with the emerging design attempted to engineer management agreement for their position.

“I was giving a design review one day, and a couple guys raised their hands and said “now this looks fine, but can you tell us what the UI really is going to look like? This is just concept, right? This isn’t “real?” That’s when it really hit home that what I was showing they weren’t getting.”

The one case receiving a non-extreme score (3) also experienced significant design conflicts. However, these conflicts were resolved through more use of discussion and review than revealed by other projects.

Case Project Outcomes

Although the transcripts showed seven of the ten case projects were eventually completed, all of the products experienced some failure or significant delays. Only one project was a success with respect to its specific stated goals and market release. The research instruments did not require specific description of projects that experienced failure or significant technical difficulty – only projects where values conflicts were apparent. These project outcomes are not intended as causal relationships to values conflicts; they are shown as post hoc supporting data, as several projects were in progress during data collection.

Outright project failure or cancellation                 50 %
Significant delays                                             30 %
No customers, or weakened product                   20 %
Successful on-time completion                           10 %

Discussion of Findings

Many factors contribute to successful product design and project completion, and numerous factors contribute to project conflict. Conflicts with institutional values in innovation projects may not fully account for these observed patterns. Other factors, including individual differences, management style, team competency and composition, and organizational defenses also serve useful explanations. However, the specific cases referenced reveal potential directions for evaluating organizational process and team participation potentially left unexamined by other explanations.

The case findings presented a sufficient, if exploratory profile of embedded values conflicts inherent in innovation processes in large organizations. A view is offered into the potential effects of institutionalizing constraints on innovation. After all, methods and practices can be adapted to fit changing business and customer needs. But values, particularly tacit organizational values, resist rapid change. First of all, personal values are generally highly stable, and do not adapt to fit projects and teams. Professional practice values represent years of enculturation into the methods and ethics of a chosen professional field, and can also be resistant to organizational adaptation. Instead the research points to the tacit organizational values in use as systematically constraining innovation and participation. For these cases, the expression of authority or power through using allowable organizational process revealed the values systems afforded by process.

Personal and professional values often conflict with officially sanctioned product innovation processes. In the study, participants cited substantial influence of hierarchy and top-down organizational structure, as a “traditional” organizational environment existed for all project cases. Participants attributed values conflicts to misuses of personal or organizational power and values of participation in teams and decisions. But are values conflicts the normal course in product organizations? Do these findings just reflect “typical organizational behavior?” And even if typical, why should any organization consider systematically conflicted innovation acceptable, especially if project and process outcomes show a high potential for failure?

Cultures of Practice and Values Conflicts

Other researchers have shown the inevitability of project conflict (Curtis, Krasner, and Iscoe, 1988) which Curtis and other consider healthy creative tension (Leonard-Barton, 1995). However, the interactions described show an organizational tendency to limit innovation and project success. The findings reveal individuals making the choice to cooperate in spite of values conflict. However, within two years most of these individuals also left their employment from the case firms.

Conflicts between different organizational groups or professional communities were common, and were identified as the conflict source in most cases. When evaluating the causes of values conflicts, the common attribution referred to “cultural differences,” and different values orientations were ascribed to cultures.

In the researched organizations, current development practices were resistant to change; new processes and even specific methods were rejected or unsupported. This occurred even when an organization did not support a current development process – the “culture” of the old process would still have an effect in preventing the uptake of new methods.

Particularly in the design professions, research has noted the difficulty in establishing consistent or effective design practices within organizations not supporting a design ethic in the culture. In the primary case organization, effective design practices were continually promoted to management, with only minimal acceptance. Even after 10 years of established product design practice in the firm, each organizational change threatened the continuance of this function.

Other research points to the effect of lock-in, whether technological (Star and Ruhleder, 1994) or cultural (Perin, 1991, Zuboff, 1988). The cultural lock-in of practices may grow from technological frames of reference (Orlikowski and Gash, 1994), wherein cognitions and values of organizational groups differ based on their shared frames. “Early interpretations” of technology use become embedded within their work practices, and these early influences hold.

However, the cultures of all these case organizations seem to avoid institutionalizing design practice. Although user interface design and usability practices had been used for years at these companies, consistent processes never gained management support, regardless of leadership. Whereas software engineering methods become embedded and routinized, to the point where software engineers find new approaches difficult to adopt, the design disciplines appear subject to different rules.

A rival explanation may be found in organizational learning. Organizational defensive routines (Argyris, 1992) underlie dysfunctional behavior in situations where rational managers understand the explicit value of a work practices but continue to undercut them through authority or decisions. Design practice presents challenges to the single position of decision power available to product, marketing, and business managers. Defensive routines show up in the case of offering explicit support to the design function, but avoiding its controversial aspects, such as feedback from the field that challenges a preferred product direction.

Values Conflicts in Design Process

Professionally-accepted design practices, such as concept evaluation, customer field evaluations, and iterative prototyping were often used by designers, then ignored by product managers. With some projects, designers independently followed processes that eventually conflicted with project team expectations, so design practices were also found in inconsistent application among projects. Product and project managers explicitly acknowledged the value of design practices such as usability or concept testing; however, they neglected the contribution of these practices on their specific projects. Both product managers and designers said users and customers were the most reliable source of requirements and knowledge, but all these projects significantly limited access to real customers. Participatory design methods or JAD sessions were attempted on two case projects, but these were also not sustained in practice. These and other design methods were codified as standard processes in three of the case firms. Since these methods were rarely used in practice, they were never institutionalized into the organizations. This pattern supports the claim for values conflict between espoused and in-use innovation practices.

Product and project manager control of projects became a significant obstacle to learning; some project leaders directed activities and changed requirements without the knowledge or interaction of other team members. Decisions and project knowledge were withheld across the team, leading to unproductive actions and incomplete shared understandings. Of course, covert management of the project and product diminished the motivation and involvement of designers and other team members. Unilateral revisions of the product, made “behind the scenes,” communicate the message that research and design activities have little real influence on the product. Knowledge integration will remain incomplete in these situations. Finally, schedule demands also diminish knowledge integration, as an aggressive deadline restricts the freedom to learn the domain and prevents gathering adequate user feedback. These issues were interpreted as stemming more from organizational values in use than project management practice values, since these behaviors were prevalent within the organization at large.

Ineffective team sharing and integration of project-specific knowledge emerged as a research claim. Product design teams learning a domain integrate knowledge from numerous informal interactions during design, creating a shared understanding and team memory. In 5 of the 10 cases evidence of significant delay or time loss is shown due to insufficient domain knowledge available to the design team. Several potential barriers to knowledge integration were identified based on the values conflict model. Members of different organizations held multiple goals and values that conflicted over time, changing the team’s focus of learning. Product managers and designers held differing frames of reference toward design that tended to polarize. Also, as team leaders overly directed product design activities during learning and knowledge integration, members were unable to freely collaborate in exploring alternatives and design approaches.

In conclusion, four general claims were posited as an initial framework for understanding values conflicts embedded in innovation management practice. These were induced from multiple case findings and iterative cross-case analysis, offering key issues that mediate project and product success. These also provide managers a concise set of rationale for evaluating organizational adoption of supportive values for innovation; these are strategic distinctions as well as social.

 Recommendations and Further Research

The four research claims point toward better organizational management of innovation. Briefly, each claim offers managers opportunities for improving participation and mitigating arbitrary use of authority.

First, cross-functional projects afforded multiple points of conflict with personal and organizational values. In hierarchical organizations, team members primarily serve their function’s values, as opposed to team values. Two approaches mitigate this common initial condition, short of actually reorganizing into customer-facing team organizations. Independent project managers invested with decision authority might establish working values and norms for team behavior, supported by a project charter held to agreement by the functional managers. Focusing on customer values for product management may be key to gaining cooperation, trust, openness, and collaborative decision-making.

Second, standard project and product management practices afforded conflict between professional and organizational norms and values. Professional cultural differences will surface within the most cooperative teams. Project management values can themselves obstruct innovation. Schedule and budget must be negotiable to include appropriate activities from all practices to support innovation projects. Project planning should always include practice leaders in decision making, avoiding conflict by ensuring participation. Effective social management of the team serves to create respect and trust, supporting team values of transparent and open communication.

Third, values conflicts emerged when standard innovation practices were neglected, or when alternative practices were used as management interventions. Processes and practices negotiated in planning should be integrated into project plans, and executed with accountability to the team. Design processes must often be explained to engineers and product managers, just as business practices must be shared with engineers and designers. Conduct of practice should allow for intra-team participation as well, allowing learning and building respect for the practice. Learning from full team participation should be promoted to the organization at large, and effective new practices should be integrated into standard methodologies. Finally, managers must resist intervening in any agreed activities, but should offer support if perceived. Intervention defeats learning and trust, both of which accelerate team achievement.

Finally, process conflicts interfered with team knowledge integration, affecting the quality of product design and development. Knowledge integration should be actively supported through effective communication and information sharing practices. Customer, design, product, and practice knowledge all must be shared, discussed, and codified to some extent to support organizational learning.

Research Implications

Innovation managers should support values distinctions in design and innovation practice, as much as “value added.” Achieving values congruence among stakeholders in systems design should be both a project and a product success factor. Values (and vision) for product design might be articulated using appropriate instruments such as values scaling instruments. A model such as employed in this research might evaluate the degree to which a design maps to user, customer, manager, and designer values. The framework could be used as an evaluation tool, for assessing the types of values influencing a design and their potential impact.

Design values as variables could also be translated into guidelines or criteria for design, following a different line of research. Guidelines would assist designers in understanding the implications of values dimensions as applied to product and interface design. For example, in the dimension of control, guidelines could offer suggestions for interface design interpreted by users as nondirective or offering choices, as opposed to the pole of coercive or forcing. This direction of research might be extended to other products than software, but each set of guidelines would be specific to a design domain, such as software, consumer electronics, interior, or architecture.

Future research should also refine and develop stronger models of values interpretation. We should be able to evaluate any product, and understanding its context of use and its market, elicit values the product presents, allowing evaluation of features or message from its social, branded, or professional design values. This evaluation process must show how design decisions were aligned with different values, as with capturing design rationale. Managers and designers should be able to determine how personal, organizational, or social values have influenced critical decisions.

To accomplish this we must establish better awareness of values in design. Design management and education must address differences in values orientations. Educators and professional societies have more recently explored the interface of product values and user values; however, we should move these considerations into the commercial realm through successful benchmark products. One way of accomplishing this would be for organizations to communicate their preferred values to customers and constituents through design values, highlighting these distinctions through promotion and product comparison.

References

1.       Alexander, G. (1964). Notes on the synthesis of form. Cambridge MA: Harvard University Press.

2.       Argyris, C. (1992). Why individuals and organizations have difficulty in double lop learning. On organizational learning (pp. 7-38). Cambridge: Blackwell Publishers.

3.       Blackler, F. (1995). Knowledge, knowledge work, and organisations. Organisation Studies, 16 (6), 1021-1046.

4.       Baum, J.A.C. and Oliver, C. (1992). Institutional embeddedness and the dynamics of organizational populations. American Sociological Review, 57, 540-559.

5.       Collins, J.C. and Porras, J.I. (1996.) Building your company’s vision. Harvard Business Review, Sept-Oct., 65-88.

6.       Curtis, B., Krasner, H., and Iscoe, N. (1988). A field study of the software design process for large systems. Communications of the ACM, 31 (11), 1268-1287.

7.       Ehn, P., Meggerle, T., Steen, O., and Svedemar, M. (1997). What kind of car is this sales support system? On styles, artifacts, and quality-in-use. In M. Kyng and L. Mathiassen (Eds.), Computers and design in context (pp. 112-143). Cambridge, MA: MIT Press.

8.       Friedman, B. (1997). Human values and the design of computer technology. Cambridge, UK: Cambridge University Press.

9.       Hanseth, O. and Monteiro, E. (1997). Inscribing behavior in information infrastructure standards. Accounting, Management, and Information Technology, 7 (4), 183-211.

10.   Hinings, C.R. (1997). Reflections on processual research. Scandinavian Journal of Management, 13 (4), 493-503.

11.   Kling, R. (1996). The centrality of organizations in the computerization of society. In R. Kling (Ed). Computerization and controversy: Value conflicts and social choices (2^nd ed.), (pp. 108-112). New York: Academic Press.

12.   Kumar, K. and Bjorn-Anderson, N. (1990). A cross-cultural comparison of IS designer values. Communications of the ACM, 33 (5), 528-538.

13.   Leonard-Barton, D. (1995). Wellsprings of knowledge: Building and sustaining the sources of innovation. Boston: Harvard Business School Press.

14.   McDonnell, J. (1997). Descriptive models for interpreting design. Design Studies, 18, 457-473.

15.   Orlikowski, W.J. and Gash, D.C. (1994). Technological frames: making sense of information technology in organizations. ACM Transactions on Information Systems,12 (2), 174-207.

16.   Patton, M.Q.  (1990). Qualitative evaluation and research methods. London: Sage Publications.

17.   Perin, C. (1991). Electronic social fields in bureaucracies. Communications of the ACM, 34  (12), 74-82.

18.   Polanyi, M. (1966). The tacit dimension. New York: Doubleday and Co.

19.   Poltrock, S.E. and Grudin, J. (1994). Organizational obstacles to interface design and development: Two participant-observer studies. ACM Transactions on Computer-Human Interaction, 1 (1), 52-80.

20.   Sachs, P. (1995). Transforming work: Collaboration, learning, and design. Communications of the ACM, 38  (9), 36-45.

21.   Star, S.L. and Ruhleder, K. (1994). Steps toward an ecology of infrastructure. In Proceedings of CSCW 94. Chapel Hill, NC (Oct. 22–26), pp. 253–264.

22.   Strauss, A. and Corbin, J. (1990). Basics of qualitative research. Thousand Oaks, CA: Sage Publications.

23.   Walz, D.B., Elam, J.J., Curtis, B. (1993). Inside a software design team: knowledge acquisition, sharing, and integration. Communications of the ACM, 36  (10), 63-77.

24.   Weick, K.E. (1993). Sensemaking in organizations: Small structures with large consequences. In J.K. Murnighan (Ed.), Social psychology in organizations: Advances in theory and research, (pp. 10-37). Englewood Cliffs, NJ: Prentice-Hall.

25.   Zuboff, S. (1996). Groupware at work: It’s here, but what is it? Panel discussion, CSCW Conference Proceedings, ACM Conference on Computer Supported Cooperative Work, 1996, November, Cambridge, MA.