Chapter 3 - Research Method

The method evolved during initial research, following both my investigation of the literature and new learning in qualitative research and descriptive methods. The literature enlightened my understanding of practical and effective methods for researching psychological phenomena in organizational life. New learning in qualitative and interpretive methods enabled my adaptation of appropriate methods for the unique focus of this study. I describe my experience with research methodology below, and then summarize the approach.

The Research Problem

This purpose of this study was to uncover and describe the relationship of individual and organizational values to the design of software products. The research started with the question “how do different values influence software products?” This inquiry led toward understanding the influences of organizational and individual values on the performance, relationships, and effectiveness of system design teams and their products. The particular focus was oriented toward values in conflict, since conflicts expose differing values within a context and enable observation and critical reflection. I addressed three research questions:

What values conflicts arise within software development teams?

To what factors do product designers and managers attribute values conflict?

How do innovation processes used in product development embed organizational values?

Instead of a single focus research problem, overlapping “problems” were found in this inductive study. The overarching social concern was for a humane perspective in system and software product design, as a significant proportion of the working population now uses information systems and software tools. Only a decade ago, custom software was more the tool of back-office administrators; but bad design now will affect the daily work and personal satisfaction of millions. The neglect of a socially oriented, humane perspective has arisen with the history of information systems in industry. The information systems disciplines, traditionally led by engineers, accountants, and managers, have produced systems reflecting their engineering and management cultures and values.

A guiding thesis asserts that these value systems shape the design of software products and information systems. In countless user interactions with systems I have noticed that the user interface, use of language, tasks afforded, and design possibilities are unwittingly oriented toward these values to a greater or lesser extent. Without reflection and evaluation of the impact of design values, products become conditioned by the perspectives of designers and their managers, based in the assumptions of business and engineering cultures.

The problem addressed by this research has been pointed to by research and thinking in system design and especially participatory design. Greenbaum (1991) describes how European trade unions that first explored participatory design approaches explicitly rejected the rationalistic, systems development perspectives in favor of a more socially-oriented approach from their own culture. However, in North America the business-based rational approach predominates.

The North American information systems industry embraces the technological imperative as a dominant style of operation, what Kling (1980) refers to as the rational style of systems organization. This approach focuses on “clear goals, tasks, specialized jobs, and procedures,” and is dominated by concerns for organizational efficiency. Because a technical approach is the only acceptable organizational style, information systems managers and engineers enjoy wide decision-making power. In my research and experience with large companies and government organizations, information systems groups often determine the requirements and design not only for systems but for business processes and work practices, based on their “ownership” of the technological tools for development. The predominate value system believes technology solutions are sufficient to the needs of complex work. Technology is also assumed to solve perceived problems of productivity, communication, and production. These underlying assumptions are important, in that they indirectly coordinate work design and organizational communication. The rational operating assumptions arise from tacit values systems or theories-in-use that reward the easy fix, the technological “solution,” and a shared perception of progress.

The case studies developed in this research evaluated software projects from the rational model, which continues as the most pervasive approach in the information technology industry. These drew from with information systems fitting the rational model or commercial software products intended for use by rational organizations.

Research Approach

Habermas (1972) makes the claim that research is motivated by interests and values (discussed by Braa and Vidgen (1997), Flood and Jackson (1991) and Dahlbom and Mathiassen (1993)). Social, personal, and political interests that are part of the researcher’s context are folded into their research. Values problems encountered in research include those social and human conflicts issuing from applications, exemplified by the commercialization or military appropriation of basic science. Further, professional and technical values are confronted in research practice, such professional values, codes of ethics or practice, and conflicts over validity of claims. Since this research concerns values in an organizational context, the value-laden nature of the research should be admitted. This discussion presents the research values and interests, and offers a context for their appreciation or critique.

Qualitative and Interpretivist Methods

In organizational research, the search for research methods that attempt to gain a holistic view of organizational issues has led to greater usage of interpretivist methods. As more organizational research continues to adopt interpretive approaches, its credibility has gained in the literatures of organizational psychology, information systems, and interdisciplinary social sciences. These literatures show an increased acceptance of interpretive case study and naturalistic observation methods over recent years, as cited in the literature review.

This summary of the research method discusses the inductive approach used, and illustrates the sequence of research activities. A “pure qualitative” approach (Patton, 1981) was adopted, using a naturalistic inquiry method, qualitative data collection, and an interpretive hermeneutic approach to content and case analysis. Overall, the research approach fits with the class of social science research methods described as interpretive field studies (Klein and Myers, 1999). Other qualitative research adopting these methodologies in organizational research include those discussed by Weick (1989, 1993), Curtis (1988, 1994) and Argyris (1992), and are primarily based on case study research.

Case studies are particularly valuable for understanding complex phenomena in context, and according to Yin (1989) when “users’ intentions, technology use patterns, and social impacts – cannot be clearly separated from the social, technological, and organizational contexts in which they occur.” Interpretive field studies are often based in turn on the “soft case” study approach, described by Braa and Vidgen (1997) as a research framework for organizational study in information systems research. They demarcate between methods appropriate for prediction, understanding, and change; and soft cases are adopted when the research intent warrants understanding phenomena. Recognizing that many studies address more than one of these intents in varying degree, research approaches are mapped to the outcomes desired by the research intents. For predictive outcomes, reduction approaches are used; understanding necessitates an interpretive approach; and for institutional change, intervention approaches are employed. The research intention was to develop understanding, with an orientation toward social change. An interpretive approach was found suitable for this research.

The specific interpretive methodology adopted fits with the class of methods known as processual research (Hinings, 1997, Orton, 1997, Weick, 1993). Processual research studies organizational phenomena, specifically issues such as patterns of behavior among groups in context, and understanding the meaning of organizational behaviors. Processual research draws from the methods of inductive grounded theory (Strauss and Corbin, 1990, Hinings, 1997), using a series of research methods to acquire data inductively, evaluate it in context, and to generate initial theory. Processual research attempts to satisfy the conflict between inductive organizational studies, which are ‘data-rich, theory-poor” and deductive studies, typically “data-poor, theory-rich” (Orton, 1997). Processual research also bridges the gap between qualitative and quantitative research, as it can fit methods from both orientations without conflict. Interpretive studies generate insights and theory from the inherent richness of data acquired from naturalistic observation and semi-structured in-depth interviews.

Other researchers support processual research for use in iterative grounded theory (Orton, 1997), and for comparative case studies in advancing theory (Fox-Wolfgramm, 1997). The processual research approach allows for iterations between theory and analysis, affording variations of the research questions to form from the data analysis itself. “An iterative process researcher suspects that researchers who can predict the appropriate research design in advance might not be asking difficult enough questions.” (Fox-Wolfgramm, 1997, p. 432)

This study drew together three approaches – interpretive case research, grounded theory, and hermeneutics - to explore the data in depth and to triangulate methods to strengthen the interpretations. Since the study also developed initial theory, both inductive and deductive research methods were selected to support theory development from the data collection. The research was limited to initial theory only, suggesting significant further study in this area.

Grounding of the Research Methodology

The research literature of the three core disciplines and their specializations (participatory design – information systems, organizational psychology – organizational process, and design studies - product design) contain numerous discussions of values conflicts and the ethical concerns in organizations. I built on key studies from these literatures to establish the issues informing this work. Critical reviews and analyses were drawn from the literature as a starting point to highlight the social concerns of information systems design. Case studies were identified and evaluated for their applicability to these social and organizational issues. The critique of the case study sample also provided a literature basis for specifying criteria for developing the research instruments. These data gathering and analysis instruments were employed for interview sessions and hermeneutic analysis of content. Emergent themes and relationships among data and models were analyzed and documented.

The deductive phase used this body of data and the models as points from which to hypothesize and present cases for bolstering interpretations. As the data was interpreted, and various models developed, a validation approach was framed to test the models. A single detailed case study drawn from the interview sample was selected and observational and document details were evaluated against the models and the interview data.

The current study focused primarily on understanding values conflict in system design, suggesting an interpretivist case study approach. The theoretical development of values embedded in organizational process also required some development of a prediction-oriented model. The following steps characterize the path of inquiry.

Table 3-1. Inquiry Methods and Reasoning Models.

 Research Methodology Overview

The complete research methodology is illustrated in Figure 3-1, which displays the flow and relationship of these activities.

Figure 3-1. Research Method.

The methodology is described in detail in the following section, Description of Methodology.

Description of Methodology

Each of the techniques employed in the research method are described to explain their purpose and application to the study. Techniques are listed as steps in the order they were conducted, as described in the flow diagram in Figure 3-1.

1. Background and Initial Theoretical Model

Prior to conducting PDE research in earnest, an initial theoretical model was developed using heuristics from prior research and experience. This model (included as a separate section at the end of this chapter) integrated the ideas and constructions generated during pre-research. This model served as the basis for testing process and values concepts during the inductive phase of research, but was not used to guide a deductive research process.

2. Literature review

The initial research activity reviewed the literature and developed research questions. The literature review spanned the body of journals, abstracts, relevant book sections, and references from articles across the works of systems engineering, organizational psychology, and industrial design disciplines.

Methodology review was conducted across the qualitative research literature, starting from phenomenological and hermeneutic studies (Gadamer, 1976, Ricoeur, 1981, van Maanen, 1991) and qualitative research and evaluation (Patton, 1990, Strauss and Corbin, 1990, Denzin and Lincoln, 1994). The methods of case study, grounded theory, and action research were investigated and documented.

The initial research questions were drawn from exploring the research in personal and organizational values conflicts in system development throughout these literatures. Three rounds of questions were developed before defining the research question and sequences of questions for interviews. Peers and faculty reviewed each round for applicability, unbiased presentation, and independent contribution to the research question.

3. Literature case analysis

Seven case studies were identified through the literature review, drawing from journals in the areas of computer science and organizational studies. Twenty cases were evaluated and interpreted for their exposition of values and moral conflict in systems design work and in design decisions, resulting in seven studies selected for analysis of values issues.

Cross-case analysis was conducted on these case studies, specifically focusing on values issues in organizational design process. The analysis involved:

Literature review of cases. Although four of these studies dealt explicitly with software product development (Curtis, Poltrock, Tang, and Walz), the other three (Orlikowski, Robey, and Sachs) were from the information systems literature, oriented toward organizational approaches. All of the cases demonstrated results with specific implications for organizational process and behavior.

Selection of criteria for case candidates. My criteria for evaluating and selecting cases was reviewed with my doctoral committee, and included the following:

Analysis of candidate case articles from relevant literature. Twenty candidate articles were reviewed for their fit against the specified criteria. Ten studies were selected based on the initial criteria.

Identification of values dimensions and issues in the articles. Case studies were analyzed to identify supporting patterns and issues relevant to developing theory. The next section in this chapter identifies and discusses the case studies and their analysis.

In both the initial and final reviews of literatures across disciplines for this research, these seven cases were found the most applicable and detailed, except for discussion papers and derivations of the same cases in other published reports. Several other research reports and cases were used as supplementary models and theoretical guidance, (Kling, 1996, Kumar and Bjorn-Anderson, 1990, and Friedman, 1997) but these did not meet the criteria for descriptive foundation cases for purposes of this study.

4. Case-based model development

Based on the case study analysis, the initial values framework for systems development organizations was designed. Values issues, specific values dimensions, and their relationships to organizations and individual behavior were organized into a framework and analyzed for general consistency, applicability, and relevance to the data collection materials. This framework, with the research questions, was used in preparing the interview guide.

The interview guide was developed from the combined initial research, using the research questions developed in the literature review, and supplemented by the values framework developed in the analysis of research models. An initial interview guide was designed, and subsequently reviewed and critiqued by committee peer Dr. Linda Tobey. This guide was evaluated in a pilot interview, and based on evaluating this pilot session, was modified before being used consistently with all participants. See Appendix A for the interview guide.

5. Individual data collection

Interviews were scheduled with participants that fit the background requirements, based on a purposive sampling approach, specifically operational construct sampling (Patton, 1990).  The unit of analysis for this data collection was the project, so project experience was required. Although originally only 5-7 in-depth interviews were planned, participation was expanded to 10, to include more participants from other product organizations and to better balance the sample between software developers/designers and business/product managers. The interviews were conducted using a printed, standardized instrument as an interview guide for semi-structured interviews. Not every question was asked of each participant, but each question asked was presented in the same way to each participant to minimize bias.

Allowance was encouraged within the interviews for participants to reflect and pursue their own interpretations from their experience. A hermeneutic phenomenological approach (Douglass, 1997) enabled participants to reflect on the meaning of their experiences during the interviews. This approach engaged participants in a deeper exploration of their ascribed meaning of organizational behaviors and interactions with teams in development projects.

The interviewing process involved: 1) A pilot interview to refine the instrument and questions, 2) final instrument review with committee members, 3) final instrument designed, 4) interviews scheduled and conducted, 5) interviews transcribed verbatim from audiotapes, and 6) analysis of interview data.

6. Data coding and integration

The interviews were transcribed and coded according to initial categories. Content analysis of the interview transcripts followed procedures drawn from Patton (1990). The structure of analysis followed the questions represented in the interview instrument. The unit of analysis was the project case, and interview questions and dialogue focused on values conflicts in software development projects. Cross-case analysis was used to draw forth common and recurring experiences and concepts.

Several analysis passes against the data drew different sets of findings. This iteration across the transcript data is a typical procedure in grounded theory approaches, using open coding and axial coding of data (Strauss and Corbin, 1990). Open coding enabled the derivation of categories as suggested by the data, a preferred approach given the inductive approach of this phase of the study. Possible categories were defined through iterative analyses of the text data, with refinements to the coding made as new data were evaluated for their addition to the category scheme. Each pass analyzed the data for features of a specific research question, developing all the categories based on recurring themes. Axial coding was then used to stabilize the set of categories in each dimension, allowing the linking of findings and the development of connecting findings. The resulting scheme of the open coding is documented in the Interpretation Matrix, Appendix C.

Analysis and coding of the data transcript resulted in several matrices, spreadsheets, and summaries used to visualize and represent the data, enabling further discovery of patterns in the issues raised by the participants. Finally, the comprehensive findings developed from the analysis were presented as the analyses and summaries in the Findings chapter. This completed the inductive research, evaluating the data to understand its content and meaning.

Following this analysis, descriptions of software projects were organized by associating patterns of statements and observations with the concepts from the values framework. This activity initiated the deductive phase of inquiry, or the initial development of theory, following a grounded theory approach. These models are documented in Chapter 3.

7. Organizational data collection

After analyzing the initial interview data and frameworks, findings emerged pointing to the effects of organizational culture on values conflicts in projects. These attributions were significant enough to support gathering data on organizational processes and the perceived values implicitly associated with product management and development. Most of the original ten participants had independently discussed the problems of organizational culture; so follow-up interviews were arranged with different participants to explore this dimension within the study.

Five in-depth interviews were conducted to follow up on these emergent findings. Participants were drawn from two of the firms represented by the original 10 participants. These participants were selected for their broader experience across many projects in their organization to which they could refer for questions about organizational processes and development process. These interviews inquired into the values in organizational processes and their impact on the organization; therefore a different unit of analysis (organization) was specified. The data collection resulted in annotated transcripts and a matrix of relationships among organizational process factors.

8. Hermeneutic interpretation - Integration of inductive data

The conclusion of inductive research required integrating all data sources and interpreting the findings, essentially a hermeneutic analysis of consolidated data. In evaluating transcripts from project cases and organizations, I focused on the organizational process questions and consolidated responses from all sources. The hermeneutic analysis was designed as part of an integrated research method – the interview data was gathered with the hermeneutic circle in mind, the data was analyzed based on the historicity and context of the organizations involved, and the interpretations were drawn from considerations of multiple voices.

The hermeneutic interpretation of the research was developed from Gadamer’s (1976) approach, which calls for self-reflection and critical analysis of the interests at stake in both the research and the scientific methods used in conducting the research. Further developing Gadamer’s hermeneutics into research methods applicable for information systems, Klein and Myers (1999) proposed seven principles from which research should draw. These principles and their application in my study are described as follows.

1.      The Hermeneutic Circle - The hermeneutic circle is considered fundamental to the interpretation process. This principle suggests that understanding is achieved through iterations in a dialogical reflection. The researcher iterates between considering the interdependent meaning of parts and the whole that they form. This principle underlies the other interpretive principles.

2.      Contextualization – The research must critically reflect upon a social and historical background of the field of the participants, taking into account the historicity of events and foregoing interactions that shaped the environment of the researched phenomena.

3.      Interaction between researcher and participants – The research process must support reciprocal dialogue between the researcher and participants, wherein the contributions of participants are allowed to affect the co-construction of ideas. This principle calls on the researcher to acknowledge and reflect on the social construction of the data derived from the interaction.

4.      Abstraction and generalization – Hermeneutic interpretation cannot be generalized directly from the findings, but must be tempered by an abstraction process. General findings are abstracted from their idiographic details and applied to the appropriate level of understanding.

5.      Dialogical reasoning – The researcher becomes required to adjust (and iterate) among contradictions between initial theoretical preconceptions and the emergent findings of the data. It is incumbent upon the researcher to allow the data to tell the story, not to fit the findings within a predetermined theory. 

6.      Multiple interpretations – Each participant in the research may offer differing and novel interpretations of the issues studied and questioned. The multiple voices should be supported in the research by specifying where individual differences among participants affected the findings. The voices should be represented in the actual words of the participants. 

7.      Suspicion and sensitivity – The researcher must be sensitive to their own biases, and must practice “suspicion” of their own systematic distortions. While suspicion begins with the researcher’s adoption of epoche to clear the field of analysis from prejudice, the notion of suspicion carries the freedom from bias throughout the hermeneutic analysis.

The intent of the hermeneutic interpretation was to develop a thorough, multi-level description of the primary issues found in the study relating to organizational processes and embedded values. Focusing on the organization instead of project, the hermeneutic analysis generated representations that informed understanding of how organizational patterns embody values and meaning in official processes, routines, and practices.

The hermeneutic analysis drew from the complete verbal content transcribed from all interview protocols. This analysis was performed on text from the ten values interviews and the six process interviews, enabling interpretation of patterns of interaction and descriptions of values systems. This hermeneutic content analysis reviewed each interview case for the unique voice and issues raised by the participant for their situation. Each project case was initially considered separately, and evaluated with respect to their context and experience of organizational processes. After this analysis, claims from across the sources were integrated into common themes. Repeated themes and similar meanings were drawn from the voices, and organized into a qualitative description for each of the two primary organizational environments studied in the research.

The organizational cases were evaluated as single-case hermeneutic analyses, drawn from the personal experience of each individual. This approach also acknowledged rival interpretations, or voices that differed from the interpreted recurring trends. One of the strengths of a hermeneutic research approach was to identify how individual differences show up in a participant’s discourse. It functions as a check against biased or opportunistic abstraction of a participant’s specific meaning into the pooled interpretations, and forces the researcher to notice when the meaning of findings differ among individuals.

For example, one recurring claim, “process management appropriated for individual influence” must also be interpreted to allow for the legitimate organizational uses of process management. The interpretation must include and balance differences among interests for using the process.

The narrative interpretations portray the themes and meanings from two of the five individuals interviewed in depth for each of the organizations represented. Although in and of themselves these are not complete and sufficient descriptions of the phenomena, they are abstracted from the grounding of extensive contextual knowledge represented throughout the findings. The two individuals representations were balanced by contributions of the other three interviews. However, these other interviews did not elicit themes from the experience of working directly with product lifecycle management processes as the two primary interview participants.

9. Activity Theory analysis

The theoretical analysis extends the findings beyond the hermeneutic interpretation, starting the deductive reasoning cycle for theory development. By applying a theoretical interpretive model (Activity Theory) to the findings, the findings are mapped to its constructs. Where appropriate, new theoretical and explanatory constructs were developed for an emerging theoretical model. This step was experimental, and designed to allow the activity theory framework to fit together the individual and organizational activities described in the data. However, this analysis was considered a separate research activity, and was not included as part of the grounded theory Findings. The organizational activity analysis and theoretical discussion are included in Chapter 5, Development of Initial Theory.

10. Initial theory development

The final phase involves developing initial theoretical models of the phenomena, to the extent possible given the interpretations. As the final analysis of the study, the results of evaluating the models against the case study are used in further refining and describing the models. This deductive analysis completes the PDE research, but provides a platform for further description and research. The refinement and final development of the organizational values process theory is documented in Chapter 5.

Structure of the Study

Participants

Two separate rounds of interviews were scheduled to collect data on the two dimensions of the study. For the first round, semi-structured interviews were employed with 10 participants, nine male and one female, ranging in ages from approximately 28 to 55. A diversity of project experience was required from the participants, and all had worked on at least three different projects involving the development of software products. Of the 10 participants, six were selected from the same company, although each had worked on different projects, and none had worked together on any of the projects described in the case reports. The remaining four participants each worked in two different companies and organizations, for a total sample across three large organizations.

A purposive sampling method was used to select the participants, based on operational construct (Patton, 1990). The study’s intent was to explore organizational patterns in product design projects involving both managers and designers, so these constructs were necessary to elicit from the participant’s experience. Five of the 10 participants were software designers or developers, and five were product or business managers for software projects. One trial participant was also employed to test the protocols and procedure, and had experience as both a designer and product manager. Eight of the managers and designers were from the same firm (referred to as Data Online Corporation, not the company’s real name). Three participants, all designers meeting the sampling criteria, worked for three computer software companies other than Data Online. Their representations offer a balance to the seven cases from DOC.

Supplementary in-depth semi-structured interviews were conducted with an additional 6 participants matching the characteristics of the initial group, to investigate organizational process phenomena. These participants were from both DOC and one of the other firms selected for the initial project interviews, and they represented the same professional practices within those organizations. Four males and two females were interviewed, all with management or design experience.

The participants in these interviews had over five years tenure with their companies, and had a variety of professional and organizational backgrounds. Three designers were interviewed, one software engineer and two interaction designers. A key participant in this group included a software engineer with research interests and publishing in organizational studies. Three product managers were also interviewed, including a senior product manager with 10 years experience, who had held positions in product and resource management, and two with prior experience in human factors and design.

Materials

Materials used for recruiting and screening participants included the invitation to participate letter and the informed consent, which all signed. Approval of the human subjects protocol (invitation letter and informed consent) was obtained via email from all committee members. Copies of these forms are included in Appendix G.

To conduct the initial interview sessions, a 21-question interview guide was prepared and tested with both peers and a trial participant. This interview guide minimized bias, by providing a basis for a consistent sequence and approach to interviews, and adopted a consistent wording of the applicable questions. This interview guide also served as the form for collecting participant personal information, and for collecting specific notes during the interview. Interviews were audio taped and transcribed as verbatim transcripts, which are available for review. The interview guide also included two scaled survey questionnaires, one to assess product-oriented values and one to assess process values, which were administered to each of the participants following their interview. The interview guide is included as Appendix A.

The second round of interviews used a 15-question interview guide to elicit discussion of values in organizational innovation process. This interview guide is also included in Appendix A.

Procedure

The procedure used for conducting the interviews was performed as follows. Participants were scheduled for a 90-minute to two-hour session in a private location, typically a conference room. They were asked to read and sign the informed consent, and asked if they had any applicable questions for the researcher.

Interview Procedure – Product Design Values

The following procedure was then used to conduct the initial semi-structured interviews, based on the instructions specified on the interview guide for the researcher to follow:

The description of the research was read, which allowed for the participant to ask any questions to clarify the nature of the study or their expectations for participation.

An opening exercise was used to set the orientation for inquiry about values systems. Participants were asked to take three minutes to reflect on their personal values and write them down. This exercise served two purposes. It allowed the participants to reflect on their own most important life values as they currently hold them, which were then considered upon reflection as questions were asked in the interviews. Also, since many of the interviews were held at the work location, this exercise served the additional purpose of enabling participants to consider the various contexts of values in their lives, and not just the work or organizational values which normally are acted upon in the work environment. They were not asked to reveal these values as part of the interview. When participants freely offered these values during the interview, it was treated as self-disclosure and as evidence of their strength as personal values.

Participants were asked to reflect on their work history and to identify a project where they had a significant role and conflict arose among different team members during the course of the project. They were then asked to describe the project and any conflict that occurred. In most cases, this first project identified was the case described throughout their interview.

Following this project description, participants were then asked a series of open-ended questions in a semi-structured format from the interview guide. In an attempt to minimize bias from the questionnaire, each question was asked in a similar voice and manner among all participants, and minimal clarification was given if requested by the participant. If it was obvious that a question would not apply in the situation of the participant, it was skipped and the next applicable question was asked. Participants were encouraged to describe situations in significant detail, and were asked follow-up questions (as part of the hermeneutic circle) to draw forth emerging meaning.

As the interview concluded, participants filled out two Likert-scaled questionnaires. The first instrument requested 6 questions about the values associated with a software product of their selection. The second instrument asked 6 questions about values associated with the design process of their case project. Each values question used a five-point scale differentiating between degrees on a specific values dimension.

Interview Procedure – Organizational Innovation Process

A similar procedure was followed for the additional interviews to study organizational and development processes. Informed consent was provided, and participants had the opportunity to stop at any time. A research description was read, and any clarifying questions were answered. I then proceeded with the 15 questions, using the interview guide as a guideline for sequence and for staying on track. Participants in these interviews were more inclined to express widely ranging stories from their experience, requiring a much longer duration in the interviews than expected based on the initial interviews. This suggested a significant depth of understanding and consideration from their experience, perhaps more than elicited from the original interviews that focused on values conflicts in project experience.

Project Interviews

Ten participants contributed to the interviews, responding to questions selected from the interview guide (Appendix B) from their experience with a specific project case. Of the ten participants, 5 were product managers or similar managerial role and 5 were software interface designers or developers. All participants had Internet product design experience, 8 with extensive experience in this area. All case projects shared a similar work team structure – a project manager, product managers representing the business interests, software engineers, and human factors/interface designers.

All participants had over five years experience in their profession, and they represented five different organizations, from three large companies with traditional corporate cultures. A weak matrix organizational structure was employed to some extent in each organization, with only one case representing a more traditional hierarchical structure. The organizations for 9 of the cases were all representative of the product organizational context (Jones, 1998), and the single infrastructure project can be classified as a systems context project, but performed for a product context organization. All product teams sampled were from large organizations, with each containing from 50-300 individuals within the software development organization. Team sizes ranged from 6 to 120, with an average of 21 members, with most teams (mode) consisting of around 20 members.

The 10 cases represented a cross-section of software development projects: commercial product development or product infrastructure – none of the cases were drawn from corporate IT or government systems. Products represented in the sample included Web search and retrieval products, CAD-CAM engineering software, enterprise retail sales, and legal research software. Products in the sample can be classified as either innovative (discontinuous) or redesigned, continuous products, with the exception of a single infrastructure project supporting a family of products.

The following table briefly describes the project cases and identifies the roles of participants. The identifier key was defined for participants as a “D” for Designer/Developer or an “M” for Manager, typically a product manager.

Table 3-2. Participant Summary.

Case Interpretation Matrix

Responses were coded and summarized in a tabular format to effectively compare across dimensions of interest. A case interpretation matrix (Appendix C) enabled summary evaluation of each case specified by the participants based on open coding. This format represented the coded form of personal values, roles and conflicts, and organizational factors raised in the interviews. Organizational factors identified included process values, both consonant (in accord with personal values) and dissonant. I also noted impacts of project conflict, and organizational values espoused and in-use.

Analysis of this summary data revealed patterns in the transcripts useful for understanding both a holistic view and for targeting specific phenomena of interest. These patterns and phenomena are described in the hermeneutic analysis below in more detail. The data was summarized to identify categories with the following representations in Table 3-3.

Table 3-3.  Case Interpretation Matrix Categories.

Process Values Analysis Method

A survey format was used following interviews to quickly collect data on the perceived values in force within the organizations represented by the case projects. Analysis of survey data supported the interpretations of values conflicts drawn from the interviews. Participants gave subjective ratings to case projects following values dimensions generated from the composite model. The instrument’s values dimensions were derived from the institutional values model described above, which structures a large set of design values inherent in organizational processes.

Evaluation of Case Studies

Cross-case analysis was conducted to inform the research problems in advance of data collection. As the literature review proceeded, candidate cases were identified and set aside for a subsequent evaluation. Twenty case studies were screened for applicability to the analysis, and of these candidates, seven were selected that fit the criteria. The following criteria were used to evaluate the case studies.

1.      The case study describes work from the domain of information systems or software product development.

2.      The cases describe a diverse constituency: Users, system designers, and managers, preferably documented with verbatim protocols from these roles.

3.      Examples of team interaction and professional conflict or differences are described. Preferably, conflicts were noted over interpretations of requirements, project activities, or how a design biases or advantages an interest group.

4.      Sufficient detail is provided in the case to support interpretation and content analysis.

Not all of these criteria applied evenly across the selected studies. Although each study fit the domain of information systems, and described most of the types of constituents of interest, other criteria may be found more definitively in one but not all studies. A recent article (Klein and Myers, 1999) presented a foundation for evaluating interpretive field studies in the IS literature. Interestingly, all of these case studies meet most of their criteria also, even though only one study (Sachs, 1995) used a hermeneutic approach. Since my goal was to elicit values constructs from the presentation and interpretation of field-based study data, the Klein and Myers approach further anchors these selected cases in the hermeneutic method.

The values systems or scales adopted for analysis of the content and statements in these studies included: Engineering-technical, organizational-managerial, personal-individual, social-political, and human values. Specific values constructs (specific attributions of value) elicited from the cases were identified by using these top-level categories as points of reference, and assigning the values dimension to the category.

The case studies selected included:

1.      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.

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

3.      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.

4.      Robey, D. and Newman, M. (1996). Sequential patterns in information systems development: an application of a social process model. ACM Transactions on Information Systems, 14 (1), 30-63.

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

6.      Tang, J.C. (1997). Eliminating a hardware switch: Weighing economics and values in a design decision. In B Friedman, (Ed.), Human Values and the Design of Computer Technology, (pp. 259-269). Cambridge, UK: Cambridge University Press.

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

Discussion of Case Studies

Case 1 – Curtis, Krasner, and Iscoe (1988).  A field study of the software design process for large systems.

This article paved the way for field research investigating organizations and projects as opposed to systems and interfaces, a type of study rarely published in the first 10 years of HCI literature. Curtis describes their preference for conducting empirical case study research, instead of quantitative studies, and the usefulness of the approach. As part of the MCC consortium of collaborating software and hardware companies in the 1980’s, Curtis’ research was conducted not only to investigate organizational phenomena, but also to deliver useful insights on these projects quickly enough to make a difference to their performance in the consortium.

Also, due to the extensive durations, difficulty, and expense of collecting data and conducting quantitative analyses, more recently software engineering studies have adopted field research or case study methods. Using interviews and observational methods, and in some cases building grounded theory, researchers have built a credible body of qualitative data since the Curtis study.

Curtis, Krasner, and Iscoe studied the major software development projects of seventeen MCC member companies and identified three design problems occurring consistently among all: 1) insufficient domain knowledge, 2) fluctuating requirements, and 3) communication breakdowns among the larger team. The study reviews these problems at the five levels of individual, team, project, company, and business milieu, and discusses the relationships of these problems among themselves, among these five levels.

Their study organized their findings across each major of the three problem areas, and discussed the results for each level within each problem. One phenomenon identified using this model was observed within the problem of the “thin spread of domain knowledge” at the team level. Teams with insufficient domain expertise incurred problems with design decision-making, since no credible body of expertise was available within the team itself. Individuals making sense of the domain during design would make arguments for their design position, and coalitions within the team would be formed, usually at odds with each other. A dominant coalition would typically obviate other positions, leading to the consensus adoption of that coalition’s approach, whether or not it was correct or best. At the project level, insufficient domain knowledge would show up as extensive time spent in design, and learning the domain through prototypes and other throwaway models. I consider these functions of group behavior as tacit processes, as they emerge as typical patterns with significant influence, and the participants in my experience are typically unaware of the pattern and of the need to navigate through the process to a clear outcome.

These five levels of organizational experience suggest the levels of interaction I observed through the interviews conducted for this study. By interviewing individuals and gaining their experience, I focused primarily on team, project, and organization, adding the dimension of process that ties the activities together among these levels.

Case 2 - Orlikowski and Gash (1994). Technological frames: Making sense of information technology in organizations.

Orlikowski and Gash present a theoretical model based on the research data of Orlikowski’s landmark case study Learning from Notes (1992). Drawing from the notion of frames from the mental models literature from cognitive psychology, they propose the function of technological frames. Frames are shared models of values, knowledge, and attitudes, in this case oriented toward technology’s roles and uses in organizations. These shared mental models represent a collective values system toward technology, and are identified through tacit patterns of behavior with technology use. Referring to Gioia (1986), frames of reference are identified as “built-up repertoire of tacit knowledge that is used to impose structure upon, and impart meaning to, otherwise ambiguous social and situational information to facilitate understanding.” They can be considered vehicles for understanding that include assumptions, knowledge, values, and expectations.

Technological frames are frames of reference for structuring experience about the nature and use of technology, or technical artifacts such as computer systems and software. The social nature of technological frames arises from sociological research in collective cognition and social construction of technology (Bijker, Hughes, and Pinch, 1987, Henderson, 1991, Saetnan, 1991), describing the understanding of social groups about technology.

Essentially, Orlikowski and Gash propose three types of technological frames:

Nature of technology – The understanding of what the technology is, does, and represents.

Technology strategy – The understanding of how the technology might be applied in the context of work and how it might facilitate business improvement.

Technology in use – The understanding and expectation for technology usage and the expectations for change and adoption.

In their study these three frames were identified and studied within each of three constituencies in the focus organization – technologists, managers, and users. The frames, or belief systems, of each of these three groups were mapped across the three categories of technology described above, showing clearly the distinct differences of values between each. For example, the technology strategy accepted by the technologists was described as deployment for “business change,” whereas managers were interested in work effectiveness. These are considerably divergent strategies, and each category held similar differences, attesting to the strength of this approach.

The implications of their study hold significance for my research. Technological frames function as a type of shared mental model that holds across a group of practitioners, becoming embedded in practice and therefore tacit. These “frames of reference” operate invisibly and as tacit knowledge, but arise from a learned model for relating to technology, at least within the professional community and the organizational culture.

The use of the technological frames construct in my PDE comes about when interpreting the transcript data. The differences in response and approach between product managers (business) and designers (technologists) to technology projects show up as striking. Basically the findings in my study resonate closely with their work, although it may even appear obvious that the essential finding that “technologists have positive values toward technology,” there has been very little follow up research on technological frames.

Orlikowski and Gash themselves offer this theory as a starting point for further empirical work, and although many researchers cite Orlikowski (1992) and Orlikowski and Baroudi (1991), the single study published with Gash remains somewhat untapped. The concept of technological frames discussed in this particular study offers a theoretical platform for interpretation of findings in the current research.

Case 3 - Poltrock and Grudin (1994). Organizational obstacles to interface design and development: Two participant-observer studies.

Poltrock and Grudin analyzed two different software development organizations and their processes for user interface design, finding obstacles to effective design in the organizational structure and development process. Although the two development groups used different processes, both supported practices that blocked the application of effective product design. The development practices in these organizations limited designer’s access to users, restricted iteration of prototypes, and limited communications among appropriate team members. Most of these practices were institutionalized in practice, but were not explicitly documented.

The development group in Case 1 had effectively developed an initial product release by relying on a “super designer” that bypassed the official development processes with relief from management, due to the overarching mission. Using a “tacit process,” this designer worked closely with all members of the development team, integrating information from all developers on a continual basis. When the designer’s mission was completed, rather than documenting and reusing learning from the previous process, the organization put in place an explicit, standardized development process. This was considered sufficient given the more maintenance-oriented development that was expected to follow.

Case 2 had employed prototyping and user evaluation processes, and had achieved progress in usability process. However, the scheduling of other development activities took precedence over usability, and impacted the use of iterative prototypes and evaluations. Ironically, due to the higher visibility of the user interface to their management, excessive top-level management decisions impacted the design and process, blocking effective evolution of the design.

Organizational structure in both cases was also found to have a limiting impact on effective development. With typical hierarchical organizations, the various groups responsible for product design and development are isolated from each other by different management groups in the hierarchy. The hierarchy increased the distance among these groups contributing to product design, and discouraged communications. Increasing the “organizational distance” led to more frequent communication breakdowns and related problems.

Poltrock and Grudin’s study relates to the current study in several areas. Their findings about the impact of explicit development processes on effective (and often implicit) design practice inform my theory of tacit organizational process. Their presentation of how organizational structure and behavior affect communications, practices, and therefore values informs my theory about embedded values in organizational process and routines. And their description of how management changes adversely affect product development are useful for interpreting the findings in research interviews.

Case 4 - Robey and Newman (1996). Sequential patterns in information systems development: an application of a social process model.

Robey and Newman reported on a longitudinal interpretive case study involving the MIS department of a large company and its use of consultants and vendors, and evaluated the different organizational processes within the case. They proposed a method for evaluating case studies, based on identifying events over time using two simple designators, episodes – long periods of sustained process without significant change or influence, and encounters – brief periods, such as meetings or design sessions, where decisions, plans, and directional changes are brought forth. This model of periodicity was based on the punctuated equilibrium model of change (Gersick, 1992; Van de Ven, 1992). Within this longitudinal model of change, three conditions of organizational behavior are proposed based on prior research (Newman and Robey, 1992) to characterize the episode periods: acceptance of a claim, claim rejection, or equivocation. These three conditions are empirically observable, are free of theoretical bias, and can be derived from documented case studies. Using a timescale to map out episodes and encounters over a case lifespan, the episodes can be characterized as one of the three conditions, allowing for further depth of evaluation based on this simple representation of social conditions.

Further, Robey and Newman discuss the applicability of various theoretical interpretations to the case, based on Kling’s (1980) six research perspectives. These perspectives include rational, structural, human relations (rational perspectives) and interactionist, organizational political, and class political (segmented institutionalist perspectives). They use five of the six perspectives as methods for evaluating the applicability of findings, and for deriving further meaning from the data by interpreting the data from the perspective of each approach. Each approach individually offered useful insights from the phenomena, and together they provided an unbiased and multi-voiced approach for interpreting the complex organizational issues of the case.

Although the use of Kling’s analysis approaches has not been specifically documented in other research, the technique might offer a valid framework for analysis of other studies and for the PDE research data. The ten cases described and interpreted in the Findings do not necessarily lend themselves to just a single social interpretation approach. By applying an applicable set of distinctions such as Kling’s, the data might be teased to reveal more robust findings and insights.

Robey and Newman’s focus on organizational patterns in the development processes brings to light the interesting model of time relationships to organizational processes such as system design.  The discovery of the periodicity of episodes and encounters informs the notion of locking-in team values and tacit processes inherent in some of the PDE discussion. Encounter periods afford the revisiting of team values and enable new processes to be defined; episodes afford the maintenance of tacit process over an extended period. Their study is unique in its focus on social processes related to persistence and change, and in describing the origin and evolution of counterproductive patterns embodied in organizational processes.

Case 5 - Sachs (1995). Transforming work: Collaboration, learning, and design.

Sachs studied two approaches for redesigning and automating troubleshooting work processes at a telecommunications company. She compared a reengineering approach with a participatory design approach. The reengineering method was conducted by analysts without user participation, using structured workflow methods to diagram as-is and to-be processes. The participatory process used a variety of methods, ranging from action research, ethnography, and quality exercises, all of which included user involvement.

The study represented the verbatim remarks of the users in the new process, and brought to light the critical issues missed when analysis was conducted without understanding the context of user expertise and the social construction of work. The work process as automated by the reengineering approach imposed a rigid workflow that disallowed communication among users, limiting the degree they could share learning about problems they were attempting to solve. By optimizing the explicit representations of work, the automated process was rendered less effective. Workers were denied visibility into information about problems necessary to understand true causes, and were also now denied communication and collaboration with experts to learn how similar problems were solved. These tacit learning situations were found to be common for the troubleshooting domain, and were therefore critical to effective action.

Sachs described the differences in worldview or frames of reference between the two approaches as organizational – explicit and activity-oriented – tacit. The organizational view was based on the assumptions that task performance was enabled by explicit analysis and redesign, training, procedures, and workflow. The activity-oriented view supported the notions of learning and collaboration, know-how and expertise, informal social networks, and work practices instead of workflow.

Sachs’ findings speak to most knowledge-based work practice. She proposes assumptions and design implications, comparing the “organizational view” assumption that people produce error which must be minimized, with the “activity view” that people discover problems and use ingenuity to solve them. From these assumptions she notes that the organizational-explicit view seeks to essentially deskill workers, impose rote work routines, design interchangeable job roles, increase automation, and diminish social interaction. The activity-oriented view is diametrically opposed to these assumptions, and asserts that skill development is desirable, development of knowledge is necessary, that collaboration and social communities must be fostered, and that learning produces reliability. These two views represent significant values conflicts, which are represented at such deep levels within work activities that they rarely are surfaced as operational assumptions. Analysts working under these assumptions, particularly the organizational view, are not given the opportunity to even question the approach – the organizational view is deeply embedded within the typical corporate culture.

The underlying relationships she points out have relevance to the PDE, as my research has a specific concern with the relative effectiveness of explicit design process and tacit practices developed organically within a work community. The assumptions stated for each of the views relate directly to the values conflicts described in the PDE case studies, and could easily have been used in my research values model. Finally, the description of work process as explicit or tacit offers a significant prior reference from which to establish the function of tacit and explicit processes analyzed within the PDE case studies.

Case 6 - Tang (1997). Eliminating a hardware switch: Weighing economics and values in a design decision.

Tang discusses the problems that can occur when economic values and design values conflict on a real-world project. Tang evaluated the design process used in a development group, observing the decision process and the trade-offs made by team members. A decision was made to eliminate a hardware on/off switch on a workstation microphone in favor of a software switch. Users trusted the hardware switch to indicate whether their workstation was private or open to “listening in.” The software switch negated trust, as users could not be certain of its true operation, as there was no physical barrier to transmitting an electronic signal as with the hardware switch.

Tang’s study comments on the design process itself, and the embedded values inherent in product development. His assertion was that the product managers favored the minor cost-savings of the software switch, over the quite real concerns for usability and privacy raised by eliminating the hardware switch from the device. He concludes by pointing out how design values should be considered a core part of the product, and the user’s view of these values should be realized. Even if the economic value of the product is taken solely into account, potential buyers might easily screen out a product such as the redesigned workstation just because of the design values and added security afforded by a competing model. Without a means to measure the intangible value of privacy and usability, product managers would have no way of knowing what design values were significant to their own customers. Continuing to manage only to the bottom line in this case would actually limit innovation, as well as sales.

Case 7 - Walz, Elam, and Curtis (1993). Inside a software design team: knowledge acquisition, sharing, and integration.

Walz, Elam, and Curtis conducted an in-depth ethnomethodological study of a software development team and described their group behavior while learning a complex domain and making critical design decisions. They described three phases of knowledge process, specifically knowledge acquisition, knowledge sharing, and integrating knowledge into the product design. As the development team proceeded through these phases, conflict was found to accelerate decision-making and learning. The study also notes the necessity for team facilitation, capturing design rationale during discussions, and fostering learning throughout the project.

The authors also described the quantity of time spent by the team in various development and non-development activities. Up to 75 percent of time in meetings (and 60 percent of project time) was used in exchanging knowledge/information and looking for answers, involving little or no design work. Conflicts among team members, such as disagreements and challenges to ideas, was resolved by team learning, as the group typically learned new information as an outcome of discussion and dispute resolution. The authors comment on the limitations to remembering design decisions, and suggest the necessity to capture design rationale, using a recorder or groupware tools.

This case study decoded transcripts from videotapes of design sessions, and analyzed the transcripts and video for patterns of behavior. They approached the study from a purely inductive viewpoint, and derived meaning from the interactions themselves. Without calling it such, much of the procedure was hermeneutic, with iterations of interpretation, and the emergence of meaning extracted from the data and its context.

This study offers discoveries relevant to the PDE research, as it describes a software product design case in some detail, enabling its use as a comparison case for the studies in the PDE research. This study also focuses primarily on the requirements definition process, where my research has also noted the majority of conflicts occurring. Its description of patterns of design emphasis over time echo the Robey and Newman study, in that these patterns were considered general enough to be represented as consistent and meaningful. The real world description of an actual design team, reaching agreements on design decision and learning through conflict, reflects a typical and natural team environment in product design. In my research, the patterns of knowledge acquisition, knowledge sharing, and integration hold relevance to the design cases, although none of the PDE cases describe all these activities. However, the PDE theory in development identifies necessary transitions in team process as affordances for values conflict and for negotiating process. This study identified two sets of transition points – the knowledge sharing continuum, and the shift in emphasis during the requirements process from knowledge acquisition to requirements understanding, to selecting design approaches. In each of these phases, the affordance occurs for offering proposals that generate conflict, test the values and knowledge of team members, and suggest opportunities for managing team and design processes.

Initial Theory of Embedded Design Values

In advance of the research, I developed an initial theoretical model to describe processes and meanings associated with designing systems and software products. This model suggested a structure for interpretation accounting for individual and organizational participation in design of systems and products, and therefore accommodating their values. Figure 3-2 visually expresses this model, defining categories of product, process, organization, intention, and knowledge/meaning. This model was developed heuristically, backed up with research in organizational behavior and design practice (Jones, 1998). However, the PDE research was based on inductive grounded theory, and I bracketed pre-existing models to avoid overly influencing the data. Therefore this model was not informed by new empirical data, but remains as a model for future development.

This model theorizes a fundamental process framework, an ontology for understanding system design processes. The diagram shows several levels of interaction of activities and roles. Activities and concepts in the design process are associated across five categories:

Product - The construction of a physical product or system

Process - The defined and accepted processes for building the product or system

Organization - Creating and integrating design teams in the organization

Intention - Defining the mission and purpose of the team and its product

Knowledge - Product, process, and team symbols and meanings

At the top of the diagram, a set of boxes describes the observable process, which is a basic set of distinctions identified in any design effort. These distinctions, found in any design process, define the system and its objects, its purpose, the actors involved, and the processes used in constructing the system. These boxes indicate direction from the “what” to the “why.” This would be the typical path of process phenomena across time. In the course of most projects, a team starts with a definition of the “what,” the thing being built, and then defines a process for building the thing. When we know the “how,” we can define the “who” involved in the process. Often the actual mission is resolved through hindsight, as products and systems often precede their purpose, which can emerge once the system defines itself.

 Figure 3-2. Initial Theoretical Model.

Underlying values provides the foundation for the purpose or mission. Although purpose is sometimes (but not always) examined in the course of design, underlying values remain undefined. This being an underpinning of design, if left unexamined, the tacit value systems remain to unknowingly affect the design and process.

Below the top set of boxes another set relates symbolically to the observable process. These boxes flow from the definition of values toward models and system specifications, to describe the direction of symbolic thinking used in this framework. This describes a flow from the perspective of values. Consider the awkwardness of attempting to derive a set of values at a symbolic level from an existing system model, such as a specification or a prototype - the value system is vague at best. However, if we start from a values position, mapping desired values to an organizational mission, then map the mission symbols to the team relationships, then to process and product - a logical progression of relationships can be made visible. I show the bridge between the observable process and symbolic level through values, although theoretically the same relation can be made between any two constructs. Yet, if the values do not map, the rest of the model loses integrity; therefore the other possible mappings are not as critical to the framework.

Below these related “flows” are typical activities described within each process area. The five categories each embody a representative design process. The design process is adapted from the Team Design model (Jones, 1998), which specifies four major phases of activity in design: Scoping, Visualizing, Usage, and Packaging. Scoping is the initial design problem definition, Visualizing includes the generation of ideas and creating visual representations, Usage models applications of design products in a context of use, such as with scenarios, and Packaging constructs a working version or packaged model. Using the example of developing an Internet information search and retrieval product, Scoping involves all the team’s activities that determine the composition of the product itself, its purpose, basic feature set, market and users. It also defines the scope of the project, its budget, staff size, and scheduling. Visualizing defines the initial look and feel of the product, its value proposition, and the relationship of features to one another. Usage defines further the tasks supported, the user’s context for interacting with the product. Packaging puts together the interaction flow as shown by screen layouts and prototypes, and presents a specification for development of the product. This generic design process describes a natural progression of generating ideas and integrating knowledge found in many contexts of product design and development.

The model in Figure 3-2 shows five distinct dimensions related to organizational activities in product design. Product design shows four activities, representing a typical process for building a physical product or system, following an iterative prototyping approach. Process design identifies four typical activities associated with establishing the process for a design effort. Organization design shows four phases of organizational and team development applicable to design efforts. The process of purpose identifies four phases of examining aspects of team and product purpose and intention. And finally the processes of defining meaning are symbolic tasks, such as identifying mission values, selecting appropriate symbols of reference, and defining and integrating the value system holistically for the product and the design effort.

This “observable” sequence shows a representative series of phases (not a strict flow) that might be viewed by observers not directly involved in the innovation work. Management, marketing, and support staff view the design process from the perspective of tangible artifacts which they can manage. Their understanding starts first with the product, then an appropriate process for building the product, then the team or organization appropriate for using that process. The two phases of intention and knowledge would typically never enter into their view of the process, yet these remain critical to the design domain and its “problem space.”

A knowledge-based or symbolic view, from the perspective of the designer, starts with their knowledge and intention, the very dimensions ignored by the observable process. Using the Internet search and retrieval product described above, the designer might actually start with intention – the user’s tasks, their context and intention for use. From there, a vision for the product inspires a team to form from the organization, this next dimension emerging from sharing ideas. This team might install its own relevant processes for the vision and the product, selecting from an array of practices available to the design team, instead of adopting a predetermined standard method of work. Finally, this team would then define the product itself, describing its scope, requirements, and physical characteristics.

However, in neither sequence do we directly encounter the underlying knowledge dimension or values underpinning the product and its design process. If these are considered at all, knowledge might be defined in terms of the skill requirements for the design team, and values could be defined in terms of the customer’s identification of the product to their experience. But rarely in practice will we find these components addressed as the originating source of ideas, expression, and values that inspire the connection of the product to the customer in the first place. An Internet search product may have emerged within the organization as an obvious outcome of a product strategy or response to a customer need. However, the design and innovation processes used in most organizations do not acknowledge the influence of knowledge and symbolic, referent values that shape the vision and opportunity for the product in the first place. When organizations ignore the originating force of vision and values potentially available in the process, the coherence and meaning of the design become lost. Management processes and project management instead take over and methodically organize the labor and produce an artifact. In many cases, all relationship to the originating vision is lost, as there are no common practices for maintaining the relationship between designer and customer knowledge and values to the building of the product itself.

Product design and other intellectual processes within organizations can be seen as influenced by tacit and largely undefined personal and organizational values. These values appear as personal or role-based positions, expressed demands, organizational behavioral patterns, and social alliances. Personal, design, and organizational values remain inaccessible to direct confrontation or coordination, since they express themselves through interactions such as participation and conflict. Their embeddedness as such contributes to their difficulty as a research subject. With a hermeneutic approach, interpreting behavioral and thematic patterns and interactions in design processes, we can identify and elicit the operational values influencing design. The PDE research starts from this perspective and direction.