Chapter 4 – Case Analysis Findings

This research investigated values conflicts in innovation from ten case studies of software development projects in large software product organizations. The findings identify the types of values conflicts experienced in development projects, and show their relationship to innovation practice in the organizations. Organizational innovation processes contributed to values conflicts, through embedding values in-use within processes. The organizational factors were analyzed independently by studying two software companies in-depth. Both the innovation project cases and the organizational study suggest values conflicts may be inherent in the official processes used in managing innovation projects.

Three research questions guided the research and maintained its direction.

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?

Values and culture are frequently identified in the design literature as an underlying source of influence of both products and processes in systems and innovation projects (Kumar and Bjorn-Anderson, 1990, Grudin, 1993, Friedman, 1996, Nardi and O’Day, 1999). This study investigated values conflict to understand the influence of personal and organizational values on product design. Four consistent classes of conflict were discovered across seven projects at a large software product company, and three other projects in other companies. A central finding was that both product managers and software designers attributed values conflict to organizational innovation processes used in their organizations. Values issues attributed to design and development process located eight factors across all cases, revealing organizational process as a source of values conflict. 

Organization of Findings

This chapter presents the findings developed from all data analysis in three sections.

Models of Values Systems were derived from seven foundation case studies selected from the literature. These prior studies generated a platform for relevant analysis of organizational values systems in the product innovation domain. These models summarized values constructs drawn from the case studies, and offered the values framework developed in advance of data collection. These models were prepared as structures for data collection, analysis, and interpretation of interviews and cases.

Case Analysis Findings follows, describing the findings from data analysis, and discussing the interpretations of these findings. Findings were developed from analysis of ten projects used as the research cases. The Findings are organized in three sections.

1.    Cross case analysis of projects. This section presents the analysis of recurrent themes found in the interview transcripts, represented as claims of values conflict in projects. These claims show across nearly all the cases, revealed through analysis of categories across the cases.

2.   Values analysis of innovation projects. This section presents key findings extracted from summary analysis of cases, including the specific conflict types and the personal and process values revealed in the research. This section also discusses the results of the product and process surveys conducted with each participant.

3.   Discussion of case findings. The case analysis findings are discussed as a summary analysis following the findings.

Interpretive Analysis of Innovation Process. This third section presents a hermeneutic interpretation of the embedded values conflicts in innovation processes. This independent study followed up on emergent findings drawing from the ten project cases. This analysis describes the patterns of conflict from embedded organizational values in the innovation processes of two large software companies.

Models of Values Systems

Model Development from Cross-Case Analysis

A values framework was developed using literature case studies as qualified sources to define a structure for values research. The framework offered a means to expand upon the values discussions documented in organizational studies. Seven case studies contributed to the framework for guiding direction and establishing common definitions.

In advance of data collection, I constructed a design-specific values model from cross-case analysis of seven frequently-cited studies, as a foundation to guide the design of the study and the data collection instruments. The seven cases were selected from the literature as foundation cases, based on the sampling criteria and analysis described in Chapter 2, Research Method. These studies were all field research studies, and used interpretive analysis approaches. Four of them dealt explicitly with software product development (Curtis, Poltrock, Tang, and Walz); the other three (Orlikowski, Robey, and Sachs) were information systems studies, with organizational orientations. These cases all discuss implications for organizational process and behavior in the product innovation context.

The purpose of this case study model was to develop an initial framework of research questions and constructs for guiding data collection and interpretation. I present this model in the Findings, since it contributed new information as well as interpretive utility. Also, it was developed from a similar interpretive analysis approach used to derive findings from the PDE research cases, and so functioned as a pilot model for the research itself. An analysis of common themes and key research problems from these cases defined the scope for the values model. The seven foundation research cases are summarized in Table 4-1.

Table 4-1. Foundation Case Studies.

Development of Composite Values Model

Throughout the investigation of innovation project values I reevaluated the definition of “values” in the context of innovation. What is meant by values constructs and conflicts in products and the designing process? What have researchers found in studying personal and organizational values, and their relationship to design and development process? What are the important or relevant values constructs to consider in this specific domain of design and process? Are there general values models applicable to product design and the design process? This research accommodates these questions, but they also lead well beyond the study.

The composite values model was constructed following three stages of development supporting the research using models from across literatures. The first step reviewed values models in organizational systems and information systems case studies. The second step integrated the common attributes from these prior models, and derived a framework to encompass a range of values constructs. The goal was to support a more inclusive description than offered by a single well-known model. Finally, this composite values model was distilled into a set of specific constructs that were evaluated by the research participants. Some values were common across values the dimensions; these were interpreted as showing agreement for inclusion in the reduced set of values in this model. Even though the values framework was an interim process used to construct data collection instruments, the framework itself revealed a usefulness for design problems, and makes a contribution for future research and design use.

Tables 4-2 and 4-3 compare and summarize the values models. I found four different families of values dimensions, each representing a different research tradition and social meaning. Design values and social values are characterized as reflecting values positions or responses of individuals, and are demonstrated as responses to personal values. These two sets were defined as individual values. In the Findings, I refer to personal values as a specific participant’s values response from experience. Although many of these values dimensions are identified from the organizational domain, they are motivators and response factors for individuals.

Organizational and technical values are characterized by their reference to institutional values systems, and are demonstrated by reference to one’s organization or occupational standards. The institutional values are dimensions identified across large organizations and professions. The four families were characterized as follows.

1.      Design values – Design values were found in two literatures. Friedman (1997), Kling (1996), Kumar and Bjorn-Andersen (1990) were the key references in information systems design, and Margolin (1998), Papanek (1996) and Jones (1992) in design studies. These design values apply universal human values to designed artifacts, and they refer to values recognizable across many traditions. Being situated in the literature of design, the emphasis in this collection was on values dimensions affecting the design of systems and products, and not basic human values.

2.      Humanistic values – Humanistic values integrated the human values constructs of Rokeach (1973) known as the most widely-cited and accepted general values model. Maslow’s (1971) values framework was adopted, drawing from the B-values (“higher” values) constructs, and England’s (1967) values model was referenced.

3.      Organizational values – Organizational values constructs were drawn from the Walsham and Waema (1994) case study, which exemplified values conflicts among leadership styles and organizational processes. Values constructs were also drawn from Crosby, Bitner, and Gill (1990), which developed a structural model of organizational values.

4.      Technical/engineering values – Drawn from Kumar and Bjorn-Andersen (1990) and Banathy (1997), these values apply to systems engineering and development practice.

Tables 4-2 and 4-3 describe the specific values dimensions included in these four values families. Selected values dimensions were integrated into survey instruments used with the interviews. Product design values were investigated using six dimensions, drawn from Friedman (1996), selected from design values from the individual values dimensions. The six dimensions selected for inclusion in data collection are indicated with an asterix. Table 4-3 (institutional values dimensions) similarly indicates eight dimensions selected for use in the research survey on design process values.

Across these four families of values, redundancy was reduced among similar dimensions. The values dimensions from across sources were evaluated for commonality, and then categories were drawn from dimensions using the same terms or intentions. This was a heuristic procedure, and was not generated from a statistical approach (e.g., paired comparisons, correlation). Although these dimensions are not orthogonal, the framework was not designed for studying values dimensions, but to construct appropriate research instruments.

Table 4-2a. Individual Values Framework – Design Values.

Table 4-2b. Individual Values Framework – Humanistic Values.

Table 4-3a. Institutional Values Framework – Organizational Values.

Table 4-3b. Institutional Values Framework – Technical/Engineering Values.

Case Analysis Findings

The following sections describe the research findings from analysis of 10 product innovation projects and the two companies hosting most of these projects. The following sections organize the findings: 1) Institutional context of case studies, 2) Summary case analysis of projects, 3) Cross case findings, and 4) Analysis of organizational innovation processes.

Institutional Context of Case Studies

Seven of the ten reference case projects were drawn from one company, Data Online Corporation (DOC). Data Online (not its real name) is a large, leading online publishing company, with roughly one billion in revenues and 8,000 employees across all of its concerns and sister companies in the group. DOC offers online access to news, business, legal, and government information. It was a leading provider before the shift to Web services, and is now also a leading provider on the Web having successfully managed the transition to the Internet.

DOC grew from roots in technology, from its early installation of very large databases, to expand into online publishing. The shift in focus from information technology to information provider occurred in the early 1990’s, as the company faced competition from well-capitalized publishing firms. By the mid-1990’s, DOC made dramatic changes to staffing and organization through reengineering. Following this restructuring, DOC was sold to a global publishing firm, and was structured more closely to a publishing enterprise than a technology company.

Corporate Strategy. DOC’s strategies include growth through sales of large contracts and through acquisition of related publishing concerns in its areas of strength. Although its past strategy regarded its databases as key to competitiveness, recent strategy has emphasized innovative product and service offerings and adding value to the data. DOC has also continued to add to its depth of publications by acquisitions and mergers of other publishing firms.

Products. Data services remain the core of DOC’s product offerings. It serves the markets for online news data from thousands of newspapers, periodicals, magazines, journals and worldwide publications. It also offers government records, financial, legal, and scientific data. Its product strengths are unique, high-value bundles of content provided for information professionals in commercial industry, consulting, professional services, and government. In particular, the majority of projects analyzed in this research involved product development for improving the data, or enhancing its access through the Internet. Therefore, DOC maintains a core competency in information technology product development.

Customers. Professional services firms, universities and libraries, government organizations, and large companies are the primary customers. They typically purchase large contracts for data services and information products. DOC gathers customer feedback on products through market research and field visits, as well as through traditional channels such as the sales force.

Competitors. DOC recognizes between 5-10 traditional competitors in online data services, and over 20 competitors across the Internet in the various niche markets its also serves. DOC remains a significant vendor of content and services in all of its markets.

Structure and Culture. DOC is organized into operating companies that manage content and services for each marketplace. Within each operating company, a strong matrix organizational structure with four management levels reports to an operational executive. Staff are matrixed to projects, which require cross-functional participation for every project due to the specialized knowledge required. Software developers and design professionals report through a product management chain (business, not technology). Although work is conducted through projects, the culture is not project-base, but remains hierarchical in orientation. As a reflection of this, most project managers are not responsible for product development, as responsibilities are diffused across roles.

Role of Innovation Management. DOC continuously works toward improving both effectiveness and cost efficiency. Innovation management in the company focuses both on products and the processes used to develop products. Although DOC has traditionally innovated more on improving the usefulness of the data, recent efforts have focused innovation on product user interfaces, product features, unique packaging of databases, and internal design practices. However, no consistent management approaches have been used across the company to organize practices and learning in innovation management.

Cross Case Analysis Findings

Transcript content analysis revealed consistent recurring claims of conflict with project innovation processes. Claims clustered around two broad dimensions, values (personal vs. organizational) and processes (professional practice vs. organizational routines).

Based on the research focus, at least one significant conflict experience was described in almost every project case. In all cases except one, the conflict was attributed to a values difference. Since the purpose of the research was to investigate values interactions in product development organizations, these themes were expected. An unexpected finding showed most of the claims representing organizational process issues, and not personal values conflicts. Three of the four themes surfaced underlying difficulties in organizational or development process, and one identified conflict between personal and organizational values.

The following sections provide a summary of the findings, followed by an overview of the projects from which the case findings were drawn, and then the cross case findings for each of the claims.

Summary of Cross Case Analysis

Four recurrent distinctions or themes were found across the cases, and were coded as claims. Most of the claims represented organizational constraints on practice or behavior. Each theme was found in over half of the cases evaluated, and some were identified in every case. Only one case showed exceptions to the consistency of these findings, reporting no project conflicts; since this participant (Hal) had minimal product innovation experience (less than two years), his exposure to projects was far less than all other participants. 

1.  Cross-functional projects afford multiple points of conflict with personal and organizational values.

Project team members expressed personal values conflicts with in-use values of the organization. Multiple conflicts were found in most cases; attributions for the conflict were made to differences with organizational values and processes. Participants also cited substantial influence from hierarchy and imposed organizational process. 

2. Innovation management processes afforded conflict between professional and organizational norms and values.

Values conflicts between project team members were evident in each case study, and multiple conflicts typically occurred throughout the case. Participants attributed claims of conflict to professional or organizational cultural differences. Intra-team conflict often showed up as differences in practice used by members reporting to different organizational functions.

3. Differences between standard and practiced innovation processes afforded project conflict.

All cases identified discrepancies between official (espoused) and practiced (in-use) innovation management processes. These included project management and oversight, product lifecycle management, software development, and product/interface design. Conflict between explicit design processes and implicit, situated design was also noted. Designers often used highly situated design practices in the daily work context of designing product features. These preferred practices were contextual and not explicitly codified, as revealed through interactions with the project team. Product managers may have performed in a similar capacity, using experience instead of official published processes.

The in-use innovation practices afforded project conflict when standard processes were ignored. Conflict between development practices constrained access to sources of design knowledge. Specifically, most cases cited the separation of designers from their source of domain knowledge, typically users or customers. This difference was attributed to standard processes, embedding practices and organizational “ownership” of customers. 

4. Process conflicts interfered with team knowledge integration.

Participants indicated conflict with knowledge integration, or the requirement for design teams to intensively generate and integrate knowledge about the target domain. For example, participants suggested teams failed to adopt customer/user information supporting design requirements, substantially constraining knowledge integration among all team members.

Project Case Descriptions

Seven DOC projects and three non-DOC projects were analyzed. Of the non-DOC projects, two did not contribute significantly in cross case analysis. One DOC project did not contribute to the analysis; the summary identifies it as an exceptional case. The projects contributing to the analysis are summarized briefly below to enable the reader to better interpret the findings. Projects are listed in order of presentation in the findings, by participant name and project.

The DOC projects were primarily search and retrieval products developed for the Internet. Two projects were infrastructure technology, with product groups as internal customers. Nearly all DOC projects were large, cross-functional projects staffed with professionals from product management (business), software product development, product design/usability, data engineering, publishing, customer service, and included a project manager. The typical project was conducted within a year period, with a 2-3 month concept and requirements phase, a 3 month development cycle, and a test and release cycle. DOC projects followed Cooper’s (1996) Stage-Gate process to some extent, and other internal policies and standard processes were followed as required for project management, product testing, and software development.

Mike’s project, the WIP product, was a Web-based interface to a multiple platform engineering system used in CAD/CAM analysis and design. This was the sole project quoted in the following analysis not drawn from DOC. The other two non-DOC projects were included in the analysis, but were not used as sources for representative citations of issues. All project cases analyzed in this study are described as follows.

1. Brian, Designer - Web Enterprise

Brian was the senior interface and product designer for the Web Enterprise product, an online news and information service designed for use in large organizations. This large Internet project was considered critical to the company, and spanned a one-year period of design and initial product development (1997), requiring nearly a second year for redesign and release (1998). Brian participated on the project during a second phase of concept design, following an initial concept phase in which outside consultants developed the first prototype.

The product team initially consisted of two interaction designers, two product managers that shared responsibilities, and a project manager. Following this concept phase, a technical lead came on the project with other software engineers available as required. The project team grew to 20-30 people overall, all but five software engineers. A major company reorganization occurred during the design phase, disrupting staff assignments and roles. Following the reorganization, a senior architect role was added as well as an internal consulting group.

Two formal processes were used in the project. The project manager followed basic project management, based on the stage-gate product development process with an emphasis on schedule and deliverables. Brian used a user-centered approach to organize the user interface and to manage all detailed design decisions. He also attempted to conduct front-end analysis, iterative design/prototyping and user testing. No documented product lifecycle management or development processes were used, except “an attempt at rapid/iterative development.”

Brian indicated the project manager did not actually run the project, but that different roles held project authority – the product manager, executives, and software engineers. Brian left the project at some point during development. Brian moved into product management in 1999, and then returned to manage a major redesign of the product.

2. Karen, Product Manager - Web News products

Karen was the project and product manager for a collection of products offered as news content products. Her products constituted some of DOC’s original Web offerings in 1996 and 1997. Karen managed a group of seven Web products, some of which were released, others which were cancelled. The staff complement for the program consisted of nearly 50 people, mainly software engineers. Karen managed these projects over roughly a two-year period, from late 1995 through 1997.

Process used in Karen’s projects included a steering committee process, a project management structure, the stage-gate product process, and a standard development process. Beginning the project with the standard processes, the project encountered internal pressures and a new executive replaced the original project sponsor. With the new sponsor, change control was disregarded – “we didn't know what feature/functions were in or out from day to day, but we made our date.” Karen described the project activity as follows:

“Not after the management structure got out of whack, everyone did their own thing. There was no "reporting" back to a steering committee. The implementation team took license where they needed to. The only thing we had to do was get the product out before the end of 1996. We threw EVERYTHING out the window that got in the way of that goal - process, good manners, rigor, testing, etc.” Karen added “I think this project was a terrific success story but it was IN SPITE OF the management and processes (emphasis Karen’s).”

Instead of an interaction design process, they managed the design through continuous prototypes, using demonstrations and functional prototypes. No product management process was used either, although the project assigned a product managers for each of the seven projects under the program. According to Karen, “That was part of the confusion. Everyone fought to get "their" functionality taken care of first.”

3. Paul, Product Manager - SearchBuddy project

As senior product manager for the SearchBuddy project, Paul managed a smaller project team of about five for a product defined for a specific customer market segment. The team included two product managers, a software developer, a technical manager, with Paul as "sponsor." The SearchBuddy product was designed to be a simple news search interface, for use by managers and other non-professional users that were not comfortable with computers. This project was initiated in 1995, before Web-based products became DOC’s mainstay.

The project team used ad hoc processes for the project, according to Paul.

“Presumably, the organization had in place processes like Stage Gate for project management, prototyping for UI, JAD for at least the requirements-producing piece of product management, and some sort of software-development process. I say "presumably" because none of these, save perhaps for iterations of the UI, was very much in evidence during my particular project. I don't think there was ever even a "formal" requirements document produced.”

Paul identified a problem typical with smaller projects, wherein official processes are not used and no informal product development processes were adopted in their place.

“No one on the team was experienced in project management--I think it fair to say that, in process terms, the team was more or less "clueless." The organizational structure and its culture at that time (including politics) was not geared to provide effective support to this project. We had some smart, hard-working people trying as best they could to cope without the necessary training in project work--kind of like trying to steer a ship without a rudder.”

Although informal processes have been reported effective in other projects (see Karen’s Web News project summary), in Paul’s case the lack of structure impaired the project.

“Not even the ad hoc methods were followed faithfully--the rules kept changing without notice as we moved "forward.” I proposed an approach to the product managers responsible for the end product. The developer reported to 2 or 3 different managers over the course of the project, each of which had a different approach, or set of rules, for development; and technical standards for this sort of product were also changed several times (sans "official" notification) while we were in development.”

Furthermore, as this project progressed, a change in senior management replaced Paul’s sponsor. Even as Paul had attempted to gain customer insight into product acceptability through trade shows and sales representatives as customer proxies, the new sponsor disregarded these efforts and insisted on late-notice personal changes to the product. This was acknowledged as a common practice, that of new executives wishing to impose their “stamp” on products by adding new requirements or changing existing features.

4. Don, Designer/Developer - Infrastructure project

Don was a senior engineer/software designer assigned to company-wide information infrastructure. The specific project reported was to integrate UNIX servers with an NT network. Staffed by 5-6 team members, this project was smaller than most, but led by a very senior technical officer, reporting to the vice-president.

Reportedly, no explicit direction was provided to software engineers, only a list of technical goals. As Don expressed it, “the task was, simply put, “go make this work.” One of the central conflicts reported in this project was that other, organizational goals were hidden from the developers. As this internal R&D project continued, the senior technical officer reportedly micromanaged the team’s efforts on a continual basis, causing Don concern for the reception of his contribution to the project. Don indicated he made a specific, tangible contribution to the project, making sure his work was judged acceptable before choosing to transition from the project to another. He reported the project continued to demonstrate technical and project difficulties even after he left.

5. Lloyd, Product Manager - Online Science

One of the senior staff managing the large Online Science project, Lloyd represented the publishers responsible for content on this product. With a core team of about 20 staff on the project for the first year, Lloyd managed product direction and requirements with a cross-functional team. The project included a senior project manager, senior product manager, very senior core development and data engineering staff, and publishing representatives. The project supported two design and usability staff, and contracted with an external design firm in advance of product release. With over a year in design and development, the Online Science product underwent a phase release to customers, and now stands as a market leader in Web-based scientific journal publishing.

All formal DOC processes were followed due to the high risks and expense inherent in the product. The official Stage-Gate process and project lifecycle templates were integrated into a schedule and work breakdown structure. These project tools were tailored extensively by process consultants, who adapted the standards to fit the unique requirements of this project.

Lloyd characterized the design process as “the mock-up approach. HF would mock up screens and I would get sign off from publishers that this was what they wanted. The mock screens then became the driving force for the engineers, and as we learned more, the mock up screens changed - which caused confusion and frustration for the developers. However, from a product and business standpoint it was seen as a most successful venture ... personally, we over engineered the product.”

As the project progressed, Lloyd indicated the processes evolved with the project. The formal approaches were left behind once the requirements and prototypes were stable and considered representative of the first release. A change control process was instituted once the prototype was considered stable, but requirements continued to fluctuate for several months even into development. Once the change control process was established, only the core staff members participating on the board made design decisions.
6. Jack, Product Manager - Reference Collection project

Jack was product manager for several products in DOC. For the case selected, the project lasted no more than 3-4 months before cancellation. During the project, Jack established requirements, maintained a small project team (product manager, publishing sponsor, software developer) and represented the product to senior management. Although Jack represents his requirements work as unfairly criticized by a manager, the project was cancelled for corporate reasons before the project started any development.

7. Mike, Designer – CAD, Inc. – Work In Progress (WIP) project

The WIP project was a large, Web-based integration of collaborative design features for a distributed processing CAD/CAM product. About 120 people worked this project, mainly software engineers and with “20 managers, up to 4 layers deep.”

CAD, Inc. uses a 6-phase integrated product/software development process called Standard Development Process. Within this process, designers and developers use formal practices from Unified Modeling Language (UML) and use cases for establishing product requirements. The process appeared to be widely followed. Mike indicated “too many” product management processes were used. But on this project, he noted they followed formal processes initially, then discarded them as time pressure for development increased after initial design. Software engineers used other formal processes with which he was not familiar, revealing some segmentation between organizations and processes in this software company.

Analysis of Innovation Projects

This section discusses the four claims from cross-case analysis, developed from rich descriptions of interactions from the transcript data. The claims are supported with specific quoted references from the transcripts.

1. Cross-functional projects afford multiple points of conflict with personal and organizational values.

Values conflicts were evidenced in each project case, and multiple conflicts typically occurred throughout the project. Participants attributed the conflicts to professional or organizational cultural differences, differences in process used by team members, or misuses of personal or organizational power. All projects were cross-functional to some extent, providing the context and potential for normal professional differences to emerge.

Values conflicts were identified from the perspective of personal and organizational values. Personal values responses originated from a individual reaction to an interpersonal or team situation. Organizational values conflicts originated from an individual response to organizational values in use, that often constrained goals or behavior. Organizational values, from the organization’s espoused values system, originated from official messages and values statements, management communications, and from official processes such as project management or product management

Every project case demonstrated instances of conflict regarding preferences for social behavior or management processes, even cases where participants did not interpret this as a values conflict. In most cases, multiple conflicts were identified as having occurred throughout the project.

Participants attributed the conflicts to behaviors and situations classifiable into at least three groups. By evaluating the responses as a whole, these situations classified as differences between professional practice and organizational process, differences in process preferred by team members, and conflicts over the misuse of personal or organizational influence to achieve goals at odds with team consensus. These groups are operationally defined as 1) Professional orientation - performing as a professional versus acting in line with organizational expectations, 2) Professional ethics, conducting work using appropriate methods, i.e., doing the “right thing,” and 3) Relationship to power, e.g., the finding of abuse of power for personal advancement.

Statements drawn from interview transcripts illustrate these conflicts.

Brian (designer) identified a personal values conflict with the product manager on his project. The values of autonomy and professional expertise were confronted by the manager’s use of direct and indirect control over his understood responsibilities.

“The values I hold when I’m doing my job - personally, I want the freedom to do the job the way I believe it should be done, and to be recognized for my contributions... My ultimate goal in my designs is to create products that our customers can use to do their jobs and that we can make money from.”

The conflict was described as:

“The value that this individual held was that it was “my way or no way,” 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.”

Brian’s personal values were identified in the interview as including independence, sharing information, contribution, teamwork, and respecting others. These were all confronted in the interaction with the product manager described in the previous excerpt.

Product manager Karen experienced an organizational values conflict that also contained a significant interpersonal element. In interactions with upper management regarding her project, she expressed the conflict as such:

“To me the value problem was in how the situation was approached. I took it kind of personally - first of all, I was out of my league with dealing with very senior executives and I was an acting project manager, so I did not have the tools to be able to deal with it. I was a woman, I was not part of the old boys club, after meeting they’d go out to lunch and talk about it, and I certainly wasn’t part of those discussions. I also felt there were hidden agendas all over the place, and they were not talking to me - there was a lot of deception going on, not being forthright or honest. This affected me, because I was honestly trying to do the best job that I could possibly do.”

Karen’s personal values found in the interviews included honesty, personal dignity, integrity, vision, and competence. Most of these values were confronted in just this one interaction. In her interpretation, part of the conflict was personal (with a specific vice-president) and part was related to the organizational culture (“old boys club”).

Offering a different interpretation in his case, product manager Paul acknowledged normal team conflict in the project, but did not experience the conflict as confronting personal values.

“Some of my values are patience, openness, honesty, get things out on the table, tolerance, sense of humor, an openness to diversity, attempt to understand - some of these were taxed. My patience was tried, I have to admit it, I became irritable at times - but on the whole I don’t feel that anything that happened violated any value I hold.”

Paul described the conflict as cultural, emerging from the nature of software development in a business environment, as “more of a differences in cultures - kind of a technical development culture and sales, marketing.” In a later interview, he described the lack of any project management or development process in the project, attributing the situation to an action-oriented organizational culture. The absence of process here enabled conflict over product direction, since either product managers or engineers could manage competing interests.

Finally, designer/engineer Don expressed the extreme pole of the personal values position with the following situation.

“At one point we had a conflict of interpersonal style, namely, what is the appropriate way to treat co-workers. A tyrant type - a tyrant who was very willing to use his power position. One individual was the sole keeper of the information and he chose not to share it. People were not given information about the ultimate goals (of the project) in order to get the work done. The technical lead withheld from individuals information about project goals that would have enabled them to independently make decisions.”

“My sense of the situation was that we were there to be used, and we had the choice of either advancing this project and not being noted for our contributions, or being scapegoats if it failed.”

This engineer’s position with respect to personal values was described as follows:

“What’s offensive is the honesty, humility, integrity, technical competence being overruled by tyranny and arrogance, not used in a way that clearly did not advance the overall good or overall needs of the company.”

“Engineering has to be about creating value, and using technical competence - which can only win in an environment where honesty and humility are encouraged. Egoless programming - those personal values just have to be there, and they have to applied toward the social values of subsidiarity, solidarity, reciprocity.., and preferential option.”

Don identifies both sets of values conflicts. His personal values were affronted by the behavior of the project’s technical lead, and he expressed issue with an organizational culture that failed to support his professional values held as an engineer.

Product manager Jack expressed apparent frustration when considering organizational values confronted in his project experience:

“We espouse as an organization the Golden Rule, and yet we see people fired and laid off and treated like garbage, treated indignantly, talent dismissed, so there’s a difference. We see an espoused value of let’s deliver what’s best for the customer, and yet we deliver data that are out of date, we don’t have sufficient data or interface, and that’s continued for many years, so there’s another conflict which we espouse values and what we actually value. We state we continually invest in product development, and yet we cut the budgets. We state that we want to attract the best talent, yet we don’t hire new people, the workload goes up and the quality goes down.”

Frustration with organizational process and management practices doe s not show in projects as an abstract complaint. Team members point to real problems and senior members take action. Soon after the period of this interview, Jack changed organizations within the company, and remains in the new role two years later.

2. Innovation management processes afforded conflict between professional and organizational norms and values.

Conflicts between different organizational groups or professional communities were common, and were identified as the primary source of conflict in the majority of cases. As organizational culture conflicts were anticipated, participants were selected and analyzed for two groups, product managers and software designers, to balance perspectives. Across all cases, the organizational entities identified represented the following groups.

1.      Upper management (vice-presidents and their direct reports)

2.      Product management (business leaders for projects)

3.      Designers (user interface or software designers)

4.      Technical (software engineers or other technical role)

5.      Users or customers

Organizational culture was considered a significant mediator of design and development processes. When an existing development process was institutionalized, new processes or even specific methods would be rejected or unsupported. This occurred even when an organization had no current standard development process – the “culture” of the old process would still have an effect in preventing the uptake of new methods. Throughout the cases, representatives of one professional group often attributed the source of conflict to the other group. Therefore, product managers blamed designers for miscommunication, and designers blamed managers for unwarranted intervention.

Product manager Paul described the SearchBuddy project where conflict was expressed continuously throughout the project, particularly with respect to the visible attributes of the product design, the user interface and its components.

“I think there was argumentation, debate or healthy discussion - about almost every aspect of this product, from how many buttons there should be, to what they should be called, to how big they should be, to where they should be on the screen, …”

This participant interpreted this as a cultural difference between the customer orientation of product managers and the standards orientation of software engineers.

“I think actually it might have been a conflict of professional orientation - because the software developers had a very different way of looking at the world from the product. We were very much engaged with how the customers practiced, and who the customer was and what might be useful to them. And our software developers - while not insensitive to that by any means - just hadn’t had the opportunity the way the way things were structured - to interact with the customers. We were essentially the customer to them - so they were much more concerned with what was the standard that was being used across the products … So there was conflict between the two cultures there - the guys who were into the latest development stuff from Microsoft and what the industry standard was as opposed to the guys who were trying to get a product out to the desktops of people who were not computer users.”

Paul’s project at DOC was perhaps atypical in the strength of project roles, as noted by the difference in leadership, wherein technical staff assumed significant project authority.

“The developers ran the product - the product managers didn’t have much say or much of as voice, of what should go in or what should stay out. Once they turned over the concept to the development group, the product managers didn’t know enough about the technological possibilities or constraints. There’s still a lot of that at our company.”

A consistent interpretation of conflict stemming from cultural differences was found across nearly all cases. In (only) one interview, another DOC product manager (Hal) could not identify conflict situations where cultural differences had emerged. However, his one year experience as product manager and only one large project indicates his lesser depth of experience from which to draw. All other participants had from 5-10 years experience in product development.

Product manager Lloyd described the very clear differences among cultures in the execution of a large Web online publishing project. The differences between geographic and management cultures in a global project were expressed:

“In fact my position was to liase the requirements from Online Science to the development organization here, so I was the bridge between two very different cultures. My “owner” was Online Science, so I had a whole bunch of conflicts to deal with, not only the corporate, but also globally.”

Differences between the product management and development cultures were also evident:

“Development engineers like to have clear instructions as to what they’re doing, and product development (management) people like to get information from a variety of sources to shape their ideas, so you always get conflicts between the business side and development.”

3. Differences between standard and practiced innovation processes afforded project conflict.

Every case evidenced some conflict or divergence between standard (official or espoused) and practiced (in-use) innovation management processes. Innovation management involves several typical processes used in organizations as guidance for managing projects and products to market. In the case studies six types were defined, including organizational management, project management and project oversight, product lifecycle management, product management, system development, and product/interface design.

This claim emerged in the analysis, but was not a values topic included in the initial inquiry. Being an emergent theme relating to the research questions, and bearing a direct relationship to the values research, a separate round of interviews was conducted to develop this finding. Follow-up interviews were conducted with five new participants (from the same target organizations) to collect data on these experiences and evaluate the innovation management processes of the two primary organizations. The findings from this round of analysis are presented in the hermeneutic interpretations in the following section.

The claim for management process conflict was described in several ways by both designers and product managers. Don, senior designer/engineer, noted how the requirements practices were used in practice as a means of power, a distinct conflict with the official approach toward requirements process.

“The way that positive values are subverted is by there not being explicit or accurately stated requirements. If there are explicit and accurately stated requirements, then that becomes the mechanism through which subsidiarity can be exercised. That’s also the interface between the business world and the engineering world, and because of the difference in the nature of sales/business people and technical/engineering people, that is the place where you have to apply process, in order to get that relationship functional, and to get that relationship to articulate.”

However, other statements referred to differences between espoused and practiced approaches to project management, product management, systems development, and product design.

Product management espoused their role as managing requirements, but often took control of interface design, a major departure from standard practice. By imposing on the designer’s activities, they diminished the designer’s ability to maintain their practices and to contribute to the project. Several designers noted this incursion, and it was considered so common that when it did not happen on a project, the designer was considered to be “lucky,” to have been assigned to a “good project.” By this, designers referred to the project as principled, well-managed, and supporting appropriate tasks for roles. As described by Brian, from the Web Enterprise project:

“The product managers wrote this requirements document, that had every bell and whistle you could think of. When they did their little prototype, they mocked-up only about 15-20% of the requirements, all of the easy stuff. When I had to do each and every requirement, they said “its hard to use, its confusing, its complicated.” The UI is only a reflection of the requirements - the more requirements you have, the more functionality that you believe should be in there, the more crap’s going to be on a web page.”

Therefore, Brian was forced to start from a prototype he did not design, and to complete the job of including an extensive list of requirements added to the product. Brian also indicated general management practices applied to product innovation and the right to make decisions:

“If you talk about work “empowerment,” to me, its empowerment “until” I disagree with you - then you’re not empowered. The thing about here that’s not a stated value - and that’s a problem - is that I don’t believe that going upward they give a crap about going below them. So if there’s a conflict, they don’t really want to resolve it if its going to affect them - so my manager and the VP didn’t take any action. The management chain didn’t take any side at all - their answer was to “move them away” - keep people separated.”

Finally, Karen’s Web News project survived various organizational battles at top corporate levels, and eventually delivered some products, although the primary products were cancelled. She observed that management encouraged different practices than those espoused, starting from the very beginning of any project, with the initial investment in product innovation.

In those days there was some visibility about what the funding was, how your project was funded, what the priority list was - you could say what projects were being done. You’d be hard-pressed to do that today - there is no master project list for the company - it’s all done by stealth. And in fact recently, we were told …to go forward on some new development projects even though there were no resources available for them. The only way I can interpret that statement is that you’re supposed to beg, borrow, steal, lie, entice, whatever else you can do - hire contractors - to get done what you have to get done. To me, that’s a value system I’m really not interested in taking part in.”

Also, in-use innovation practices afforded project conflict when standard processes were ignored. In most cases differences arose when standard accepted development practices were ignored. Cases were described where teams recognized and understood the value of a development “best practice,” but failed to use the practice on the project. For example, although nearly every research participant acknowledged customers as the best source of product requirements and task knowledge, most projects allowed very limited access to customers if at all. Furthermore, even when designers specifically attempted to gain access to customers for use in design, they were separated by project schedule or role from the users or end customers. Conflicts especially emerged when basic design goals were not met following the in-use practices. Designers standard practice includes drafting multiple alternatives for a product interface. When product managers forced a decision to use a single interface without alternatives, the design goals and values failed, even if the product manager supported the single design as sufficient.

Most reported practice conflicts surfaced during a project’s requirements definition phase. Participants attributed conflicts during requirements as arising from four sources.

1.      Conflict over management of the design process. These included the actual design practices used or allowed, the extent to which designers were allowed to follow their preferred practice, and the appropriate timing of activities within the project.

2.      Professional differences in making design decisions and decision rights. These differences included whether a product manager or designer made specific design decisions, whether decisions were made by authority, by data, or by consensus, and whether any agreed process was employed for making decisions.

3.      Conflict over uses of power in team leadership. Leadership differed across most projects. Some projects were led by specific individuals with recognized leadership, others assumed power over the team, and other projects were directed by organizational power over team direction.

4.      Conflict over the validity or quality of requirements. Designers perceived requirements generated without customer feedback as questionable. Also, product managers were reported to have applied arbitrary quality standards to requirements documents.

Don, a senior engineer, described a typical conflict over use of power, decision rights, and managing the design process.

“One individual was the sole keeper of the information and he chose not to share it. People were not given information about the ultimate goals (of the project) in order to get the work done. The technical lead withheld from individuals information about project goals that would have enabled them to independently make decisions.”

With other cases, the project team disagreed about how to best define specific requirements for the product, and were unable to reference design decisions to a defined user need. This situation occurred with Brian and Karen; when their teams had developed a prototype of the product, the product manager was promoting new features not included in the original design. Conflict emerged when differences were raised within the team by other professional roles, and team members had no access to data based on real user feedback to support their claim for the design.

An example of this process occurred with Paul, where the product design fluctuated between direction from the product managers and changes made by the development team.

“We were in a meeting and had gone over the last iteration and we had some discussions about the product. There was one instance where we were naming the buttons, and we looked at the names on the design and they turned out to be different, they had been changed into something conventional.

Sometimes its chore not to yell at the developer - he wasn’t making these decisions, he was a nice guy, he knew what he was doing, and we knew he was putting lots of his personal hours into this - but we had expected to see something else.”

And in this case, the fluctuation persisted to some extent due to the unavailability of customer data, and the absence of a customer feedback process for the product design.

“I think we probably fell down on getting the customer input - perhaps by showing these things at professional meetings - which is where we got a lot of our initial feedback and validation - instead of using human factors and other current processes we use now. 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.

Key people on the team who were consultants to the sales force were therefore resistant to this product - I doubt if it’s in the hands of any customers, and I doubt if anybody is actively selling it.”

From the designer’s viewpoint, the same conflicts were apparent, and even voiced in similar ways. Lynne, a product designer with the Autoline Data Systems company, expressed the requirements conflict as moving ahead with product decisions without adequate user data.

“There’s this idea that the product managers can eventually think enough like the customers to know what the customers need, so we can move ahead with product decisions without staying in close contact with the customers - on the other side, they have to hear the negative side of the customer’s feedback, the trouble calls.

Sometimes it gets frustrating because they look to one person or two people to embody this “voice of the customer, ” such as “if she think it’s OK then it’s OK.” It’s hard for me to figure out sometimes how to get all this information in and have it make an impact on the product without it crippling the organization.”

As described in the project summaries, some projects disregarded official process once the project was well underway. Typically, once the project moved past the riskier, ambiguous front-end phase of requirements definition and into development, organizational pressures to produce diminished the team’s maintenance of process. Such basic practices as regular design reviews, design documentation, and even testing and evaluation were often neglected until product release to the market. The observation can be made that project team members continue to claim their adherence to the official process, but team attention to process has diminished to the point of neglect.

4. Process conflicts interfered with team knowledge integration.

Five of the 10 cases evidenced significant delay or time loss due to insufficient domain knowledge available to development teams. In other cases the issues stemmed from unavailable technological knowledge or differing knowledge claims between engineering and business team members, leading to project confusion or product delays.

Team integration of appropriate knowledge is considered a necessary factor for successful software design (Walz, Elam, and Curtis, 1993). As an ongoing activity, it continues through a project lifecycle, and was described in different ways in case transcripts. Interference with integrating knowledge arose from team interactions, organizational events, and management processes. One barrier to knowledge integration related to the multiple goals and values within the same team, from subsets of members belonging to different functional organizations. Product managers and software developers used differing frames of reference toward design. If their frames of reference were not resolved early in the project’s lifecycle, they tended to drift toward their respective polar directions. Project managers were unable to make sense of post hoc decisions if they had not participated in the decision process. DOC’s product manager Paul expressed this as:

“So we would find that things we thought we had made decisions on would show up in a different form in the next iteration because standardization had occurred, … and it had nothing to do with what we had expected to see, so essentially product decisions were being made from the design group. They were going down a perfectly valid path trying to standardize development, but they were causing some disconnects with the product team.”

Another obstruction to knowledge integration surfaced when team leaders exercised direction over the product’s design during phases where learning and knowledge integration were in process. At times leaders attempted to direct project activities without the knowledge, feedback, or interaction of the design team. This typically happened when a product manager believed specific results were achievable by directing software developers independently of the full team, as in the cases of Brian from DOC and Mike from CAD. Decisions, and therefore learning and knowledge, were therefore unavailable to the team, leading to unproductive project activity (“churn”) and incomplete shared understandings of requirements or design artifacts.

Schedule demands posed a source of interference, as cited above, preventing the gathering of adequate user feedback to early product designs. Further, team leaders had seized opportunities during development to make decisions affecting product design without sharing details. Examples in the literature case studies show leaders using opportunities to push their preferred functions, avoiding confrontation from team members, but also diminishing trust required for sharing knowledge.

Senior designer Brian described this situation in the Web Enterprise project.

“Another thing the product manager liked to do was go talk the engineers and describe to them how it was going to work so they could get their engineering plans around what she thought. And of course, when we talked with them about our perspective, with all of us together, they had already bought into some of her ideas, making it difficult to change things at that point.”

Product manager Lloyd described how his job was defined to “liase the requirements from (parent company) to the development organization here, so I was the bridge between two very different cultures.” In this product management role, the challenge was to maintain communications and appropriate direction between management and the development team. In some ways, Lloyd and other managers functions as professional knowledge integrators, to ensure that all parties understood each other. Of all the projects researched in this study, Lloyd’s product was the most successful in reaching stated goals of time to market and market position. However, its development process also evidenced organizational conflict and knowledge sharing problems.

“My management in brief were saying “this was the way we were doing things.” So I would have a tendency to agree with the user interaction and product people here - but I had to come back with the message “this is the way its going to be.” I usually softened the blow before they came here … but I saw both sides of the coin.”

“So that’s why I look at the team approach to things - and there’s a lot to be said for putting people in from different areas on a team, but even in those teams quite quickly they will form a hierarchy, where a strong opinionated person will tend to take charge. Even though cross-functional teams work, they still are limited - I don’t know how to solve it.”

Analysis of Innovation Project Values

Three sets of findings were developed from the ten project cases, organized as follows.

Composite case analysis. Case data are summarized to evaluate the composite of cases, including organizational contexts, team roles and composition, formal and informal processes, and product types.

Process values analysis. Analysis of personal values in conflict with processes or with implicit organizational values.

Product values analysis. Analysis of values conflicts affecting product design, or where a product reflected values in conflict with the personal values held by the participant.

Composite Case Analysis

Composite analysis of all cases summarized project characteristics, enabling comparison of cases and allowing reference to differences among cases. Analysis included participant roles and types of conflicts, personal values, and organizational factors, and identified impacts of conflict on projects, and the espoused and practiced organizational values.

Participant responses to interview and survey 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.

These analyses were derived from open coding and analysis using an interpretation matrix. The transcript text was evaluated for recurring themes, and each instance of conflict was coded as a unique type. Personal and process values were not coded, but were drawn directly from the transcripts. Any values statements revealed in the transcript were extracted verbatim and within the context of the specific questions, and were not afforded interpretations that might change the participant’s personal meaning.

Types of Conflicts

Transcripts of the ten cases described 28 unique conflict types, with all participants identifying conflicts with aspects of the product design process, and 80% describing conflict with control of product design. Since these two types of conflict were so pervasive, they became a pivotal research direction. The following percentages of participants cited the following conflict types across the cases, listed in rank order:

Conflict with design process                  100 %
Control of product design direction           80 %
Uncooperative team members                 50 %
Organizational culture conflicts                40 %

Other conflict types were considered minor, falling to less than 40% of the cases combined. In a study focusing on specific conflicts, these variations of conflict might be of considerable interest. For the purposes of this study, attention was given to values conflicts that recurred as significant themes across the interviews.

Personal Values

Personal values were drawn from the transcripts as they were mentioned, and coded as verbatim. Personal values were not specifically requested of participants (see the process in the interview guide, Appendix A), as the interview guide did not ask participants to reveal their personal values as reflected in the pre-interview exercise. Instead, values statements were elicited only as self-disclosure revealed specific strongly-held values statements in the context of other interview questions. This was considered a test for strength of personal values, to allow values statements to surface during the related questions.

Participants self-disclosed a total of 28 unique values, an average of 4.4 personal values statements each during the interviews, without having been prompted for the disclosure (See Appendix C for the Interpretation Matrix identifying these values). Participants overall disclosed the following five value statements, in order of prevalence.

Honesty            50 %
Competence      50 %
Teamwork         40 %
Openness         40 %
Integrity            30 %

These five values constructs were cited during interviews as core values confronted by conflict with project situations and organizational values. This set of five values statements should be considered representative of the participants sample. Of the remaining values statements, none were cited by more than two participants. Semantic similarity was also indicated among many of the disclosed statements, showing potentially even stronger indications for these values. For example, “openness” shares meaning with “sharing.” Further research with the values framework would clarify the associations of values in the organizational and design domains.

Process Values

Data analysis clarified the types of values conflicts inherent in the process issues identified by participants. These process values refer to the participants’ interpretation of values in the product design process for their project. Their statements were drawn from inquiry about the values apparent in their case projects’ design processes. These are also coded in the Interpretation Matrix, in Appendix C.

This analysis revealed ineffective organizational behaviors built into the product design process. Analysis identified both “positive” or effective process values and “negative” and unproductive behaviors or counter-values. Of 19 unique effective values noted, the most frequently cited process values noted in their experience included (in rank order of frequency):

1. Customer focus
2. Information sharing
3. Appropriate roles used
4. Teamwork
5. Independence - Autonomy                 
6. Openness

Unproductive or obstructive process patterns were described throughout multiple points in the interviews, and surfaced more as patterns of activity than as specific values statements. Whereas participants could identify “teamwork” as a positive process value, the negative counterparts were described throughout the transcript. Therefore, these process issues were elicited from both the transcripts and the matrix of summary statements. The following process patterns were most frequently identified by numbers of participants and frequency of citation.

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

Case Project Outcomes

Even though the transcript data showed seven of the ten case projects were eventually completed, all of the products experienced some failure or significant delays. Only one project described was a success with respect to its specific stated goals and market release (Online Science). The research instruments did not require specific description of projects that experienced failure or significant technical difficulty – only projects where values conflicts were apparent. The project outcomes of the cases follow.

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

Most projects were completed in spite of claimed management and process constraints. Seven of ten projects were reportedly completed (two reported failures were later revised and completed). Three projects were cancelled outright. Evaluating the project outcome should also assess marketplace performance, since many aspects of product innovation and design directly affect market acceptance. Being out of the scope of this research, product success in the marketplace remains unexplored in the analysis.

Analysis of Process Values

A survey followed the interviews to collect concise impressions from participants of the values in use in the case project’s organizations. Analysis of survey data supported the interpretations of values conflicts drawn from the interviews. Participants assessed their project’s values following dimensions generated from the composite values model. Table 4-4 summarizes the results of the process survey:

Table 4-4. Summary of Process Survey Results.

The process values for seven of the eight cases evaluated were rated strongly in association with more authoritarian values. For five of the six dimensions rated, the averages across all projects were within one rating 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. Considering each dimension, the summaries give insight into the accepted everyday conflicts in software product development projects. The following analyses of survey ratings are supported by excerpts from the transcript, suggesting a contextual rationale for rating the projects as found.

1. Team participation

The average score of 4 suggests participants in the case projects experienced design and development teamwork as non-participatory. Case interviews revealed individuals pursued tasks that supported the overall team but did not participate fully in design decisions, planning, and project direction, and essentially worked as individuals and not as collaborators.

Three participants had rated their projects as very non-participatory (4 or 5), and only one highly participatory score (2). Reviewing the high-scoring SearchBuddy project showed Paul, its product manager, believed their process was participatory. The other two projects showed large differences in power and group participation. The transcript of even the highest rated project revealed that numerous incidents of communication breakdown occurred during the project. According to Paul:

”Some conflict arose because the person who was our main designer was also reporting in to the design group, up a different chain, a different organization - they were in the process of setting standards for this class of products while we were developing that product. … we were not in the communications loop to formally let us 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.”

This portrays how even a project rated the highest in participation evidenced dysfunctional patterns of team participation. Other projects indicated a pattern of very poor participation, as described by Don, senior engineer on the Infrastructure project (scoring the lowest rating of 5):

“At one point we had a conflict of interpersonal style, namely, what is the appropriate way to treat co-workers. A tyrant type - a tyrant who was very willing to use his power position. One individual was the sole keeper of the information and he chose not to share it. People were not given information about the ultimate goals (of the project) in order to get the work done. The technical lead withheld from individuals information about project goals that would have enabled them to independently make decisions.”

2. Cooperation

3. Customer-orientation

This category scored an average of 1.5 (where 1 was the lowest possible score), indicating that no projects were considered customer focused. This dimension evaluated whether “design and development decisions were more management-driven or customer-oriented.” The unanimous response was that management considerations prevailed in these project cases, even in cases where significant customer data had been gathered for the purpose of making informed decisions. Both professional groups interviewed, managers and designers, believed this was the case. Both groups also made frequent references to the problem of access to customer data from which to base design decisions. This was found to be a major problem in several projects, as characterized by the following statement from designer Brian on the Web Enterprise project:

“The value that 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.’”

Paul, the senior product manager at DOC, 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 - perhaps by showing these things at professional meetings, which is where we got a lot of our initial feedback and validation, instead of the human factors and other current processes we use now. 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.”

4. Task coordination

This dimension received an average of 3.75, where coordination of tasks in development ranged from “emergent, based on skill” to “pre-determined.” Most projects in the sample assigned job roles and held them constant through the project; project management did not consider leveraging skills as they emerged. This was characterized by statements in the transcript, such as product manager Lloyd’s commentary on the cultural differences of task coordination:

“I’m here at this moment to do a job - in my being here 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 projects, perhaps an exceptional case, scored very highly in this dimension. 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. So, if I have a prototype instead of a requirements document, I won’t knock myself out to do a requirements document if the prototype is sufficient. Same with checkpoint meetings - if I need a project management schedule tasklist to keep my project on schedule, fine - 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.”

5. Requirements conflicts

Conflicts in product requirements tended to be resolved by means of authority rather than consensus, as indicated by the low average score (1.5). In nearly all cases, when product requirements issues emerged as conflicts, the resolution was handled by management intervention. Team participation was not involved, nor customer feedback solicited to address differences with requirements. In several cases, requirements differences were the source of conflicts that maintained animosity between professional groups on the same project team, or between management groups across the organization.

Examples of conflicts in requirements included a range of situations. Some requirements conflicts were within the project team itself, such as noted in CAD designer Mike’s case, where a competing team member struck numerous requirements from a project scope list.

“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. They’ve all been changed back, or most of them. 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.”

Other requirements conflicts came directly from upper management, including product manager Jack’s inability to gain necessary feedback or support on writing requirements on the Reference Infrastructure project:

“One criticism I received was that I did not write good product requirements - I offered to work with that project manager to specifically identify which requirements were not adequate, but this never occurred. Even though I specifically invited them to.”

Another statement from product manager Karen reveals difficulties in attempting to gain consensus on requirements for approval of the business case for investment:

“It ended up being an argument among the various VPs - the VP of my particular division was on my side and was supporting me. The VP of IT was dead set against it …he wouldn’t explain what he was doing or why he was doing it and how it wouldn’t work … he blocked the way in whatever manner he had available to him - which was basically that he was one of the votes on the steering committee. And he would not sign off on my business case - I would give him the revised business case and he would come back with 47 questions - I would answer those …, and he would come back with another 20 questions. And this went on for a little while, and I said to myself “I can’t take this.”

6. Design conflicts resolved

Design conflicts refer to differences expressed within the team or among management groups. Product design conflicts differ from requirements conflicts. These occur during the visualization of the software product’s user interface, when disagreements normally arise between designers and product managers over solutions that meet the needs of the design and the requirements. In most cases, design conflicts were resolved more by management decision than by discussion (or consensus). The very high average score of 4.5 suggests that discussion was not typically allowed for settling design conflicts (only one case was scored lower than 4).

Other cases in the transcript show frequent examples of design conflict. In one example described by designer Mike on the CAD company’s WIP 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 them they weren’t getting. That was the only time they confronted me, but there were lots of times I heard stories, … that they kept going to them around my back, going to the planning manager and saying “we can’t do this, this will take too much time, …” But they never really gave it a proper analysis to know whether they could or could not - they only knew they feared it, because it was an unknown.”

Although Mike’s project was not from DOC, it shows a clear use of political means to manage opinions related to the priorities for features and design in a similar organizational situation.

The one case receiving a non-extreme score (3) also experienced significant team conflicts. However, these conflicts were resolved through more use of discussion and review than indicated by descriptions and observations of other projects. This tolerance for some variation during design was expressed by product manager Paul.

“The actual developer on our team - I think he felt probably the most conflicted of all - he was able to see what we were trying to do, but on the other hand he was constrained by his management. I felt like if we were adequately representing the voice of our actual end-user/customer we should not be doing processes for our internal convenience. … We kind of muddled through. I think from our point of view we kind of basically ended up capitulating to the technical changes. It was not so much what we were implementing, it was the lack of communication.”

Discussion of Process Values Impacts

Conflictual situations were expected in the case projects analyzed, since the selection criteria was based on identifying projects where conflict was experienced. The study did not attempt to evaluate the frequency of such projects, although the transcripts reveal participants believed the case projects typical of their organizations. The following discussion further evaluates the impacts of these values conflicts in the organizations.

Participatory teamwork. Project participants experienced teamwork on innovation projects as non-participatory, meaning that the team was managed to limit the participation available during analysis and design. Individuals pursued tasks that supported the overall team as individual contributors. Participants interviewed were among the most senior of all project members, yet they did not participate fully in design decisions, planning, and project direction. They essentially worked as individuals serving roles and not as collaborators.

The transcript of even the highest rated project revealed that numerous incidents of communication breakdown occurred during most projects. Even the project rated as highest in participation (Infrastructure) showed authoritarian patterns of team participation. In this case the project technical lead had established a gatekeeping role and made unilateral project decisions. Beyond project control, the technical lead also interfered with technical decisions for design and development normally afforded the engineering staff. Evidence from the interviews shows this style of “leadership” was not uncommon.

Cooperation. Cooperation was the most positively rated value, and participants expressed how project team members cooperated professionally and interpersonally. The transcripts show conflict between professional groups (designers and managers) and between individuals holding power, but this appeared to affect participation (in design and decisions) more than cooperation (supporting other members of the team). This might be explained by noting there were few instances of competition for position or power among team members of similar status. From an organizational perspective, cooperation and support of team members would not diminish job evaluations or inhibit career aspirations.

Customer-orientation. No projects were considered customer-focused by participants. All participants 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 having shared the ideas with others on 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.

In several cases a significant amount of customer data had been gathered from prototypes with field users, for the purpose of informing product design decisions. Customer data was ignored in different ways, but to similar effect. In the Search Buddy project, product managers attempted to gain customer feedback but were unable to use it, as both developers and new senior managers ignored their findings. With Web Enterprise, customer feedback was gathered from usability evaluations of product concepts. This data was ignored by the product manager, who made design decisions opposing these findings, and avoided discussions by colluding directly with software engineers. In some projects, such as Web News and Reference Collection, no channel for customer input or feedback was considered in product planning.

Product managers used different strategies to ignore or diminish the effectiveness of user evaluations, thereby maintaining product authority. A simple strategy was to ignore evaluation findings and pursue a predetermined course of decisions or requirements. This was typical when the customer information was presented through a channel that had no authority to overrule the product manager. Another strategy was to outsource usability and customer research to market research consultants instead of using in-house usability professionals. In this way the management could claim unbiased findings, and even engaged usability specialists to write the test plans and scripts for market researchers. As any researcher would expect, this approach was flawed from its initial assumptions to its execution. Market researchers, although capable of performing scripted evaluation, are specifically unable to forward meaningful recommendations within the context of design. Attempts to make design recommendations are universally trivial or superficial, since they have no access to the design or customer’s work context.

Finally, product managers have used market research as a power mechanism, setting up the evaluations for a prescribed result. A recent evaluation conducted with a large number of recruited customers evaluated only a single interface, when several alternatives had been prototyped and planned. The last minute decision to test only one design – the product manager’s preferred model – obviated any other findings that might have offered better design solutions or even future requirements based on interface comparisons.

A common theme in the interview sessions indicated the customer’s values should be primary to the product’s focus. Most participants answered that the product’s customer values should be considered as the driving product values. Given this finding alone, we could predict conflict on projects where customer feedback was not allowed into the design process. Avoiding or misrepresenting the customer focus signals the potential for severe market misfit, and threatens product success or even survival.

Task coordination. Task coordination referred to the effectiveness of task assignments, and to how roles were managed in projects. The research projects showed that nearly all projects assigned job roles and held them constant through the project. If team members learned or demonstrated interest in new skills, project managers did not support their interest or potential contribution with enlarged assignments.

In the case of product managers, it appeared the related problem of role confusion was more problematic than task coordination. Product managers frequently fulfilled the practical roles of project and development managers, and adopted a range of roles as required by the organization and project. No discipline or body of literature specifies practices for product management, and the organizations (as researched) supporting this role provided no professional training in requirements and team process. This was highlighted by statements such as product manager Jack’s:

“This company doesn’t have a clear view of what does a product manager do, what does a project manager do - and in fact, in many instances, the same person serves as a product and project manager, so there the roles conflict all the time. What’s a product call, what’s not a product call - so roles are confused, and upper management’s values are not clearly communicated - even though I’m quite certain upper mgt. thinks those values have been communicated.”

Constraining team members by task and role impacts productivity and competitiveness in the long run. Holding roles constant through a project supports the project manager in staffing and planning, and enables reliable coordination of team tasks. Locking-in roles too specifically may establish a culture that rewards maintaining existing skills, which, although useful across projects, keeps both employees and organizations from creating new knowledge. If skilled design and development staff are constrained too highly in their learning and growth, they may leave the current job to pursue challenge. The truism that “good people leave first” during organizational upheaval reveals those with the most desirable skills recognize their diminished prospects for growth and challenge and have a wide selection of opportunities. Software product organizations cannot afford allowing skilled staff to leave or to constrain designers and developers in confined roles. Knowledge drain or stagnation are significant risks, affecting future competitiveness by maintaining outdated skills and finding competitive new hires unavailable.

Requirements conflicts. Project managers resolved conflicts in the requirements process through their role authority. In the case projects, product managers solicited feedback on the specifying of requirements, but did not seek a consensus on the response. Although customer feedback was desired for prototypes reflecting the requirements, only one project actually used customer/user evaluation as a means of validating requirements (Online Science).

The transcript shows many projects experienced the requirements definition process as a battleground of competing interests, which is consistent with research in this domain (Jones, 1998, Sharrock and Anderson, 1996, Brooks, 1995, Curtis, Krasner, and Iscoe, 1988). Conflict should be expected in the requirements phase for any complex project, as different designs and features are presented, negotiated, and resolved. However, in only two of the case projects were the requirements conflicts resolved to enable productive team cooperation.

The case study organizations used official internal templates for documenting requirements, although standards for the quality of their content were almost non-existent. Product requirements were considered “owned” by the product manager, implicitly establishing the relationship within the team of the product manager as “customer.” Their “ownership” of the product requirements specification invested a great deal of authority on the project, which was used by different product managers in different ways.

As differences arose between project team members during requirements definition, power relationships were revealed. Software engineers maintained significant influence in their response to requirements; but if they expressed difficulty with a requirement, it was typically due to its infeasibility. Engineers and developers rarely questioned the value or rationale for requirements, so their power was strictly technical. However, product designers and usability evaluators directly questioned the rationale for requirements, as they had direct contact with users in their work and attempted to represent the customer’s interests. Designers were also responsible for designing a user interface representation of the requirements, and were in the best position to evaluate the fit between product requirements and user needs. This orientation toward the customer maintained a continual tension between the roles of product manager and designer. In these ten cases, product manager interests continually overruled design proposals from designers, regardless of the availability of user feedback, usability test results, or design rationale. These conflicts based purely on authority became the source of political tension, establishing a structural animosity between these two roles and other interests on the same project team.

Requirements conflicts surfaced continually in projects. Most conflicts emerged in project sessions, such as Paul’s project where developers changed product functions without team discussion, or the covert behavior in Mike’s case, where a team member struck requirements from a scope list. Upper management also inspired requirements conflict, such as in Jack’s case, when questioned about his product requirements.

Figure 4-1 shows how the convergence of differing demands creates the conditions for organizational conflict over requirements. As a product development effort moves through the phases from planning through design and development, the needs and uses for project structure shift for both product managers and software developers. Product managers require more control and structure in the early stages of the project, to ensure their requirements are adequately managed through the process. As the product takes shape conceptually and moves into development, the product management role is less clear, but development requires more structure and control. During the design period – when prototypes make requirements visible, revealing both product design and technological limitations – conflict is most likely to occur.

Figure 4-1. Relationship of management and development structure over development phases.

Design conflicts resolved by management. Product design conflicts differ from requirements conflicts. During the visualization of the software product’s user interface, disagreements normally arise between designers and product managers over solutions that meet the needs of the design and the product. In most cases, design conflicts were resolved by management decision, as they were with requirements issues. This shows the role authority of the product manager extends to the responsibilities of other roles, even when the design role was specifically defined as responsible.

In Mike’s WIP project for example, team members in conflict with the emerging design attempted to engineer agreement from management for their position. In Lloyd’s case, minute specifications in the user interface, such as field labels and wording, were settled by an executive taking close interest in design affairs.

This finding overlaps with both requirements and task coordination, and they would be expected to co-vary if measured in practice. However, they show up as distinctly different phenomena. If task coordination is highly constrained to fixing responsibilities by role (as found), we would expect decision-making to be held solely by product management. Also, if tasks were allowed to emerge based on learning and skill, decision making would necessarily be delegated down to those working across activities with the insight necessary to make informed decisions. Instead, it appeared that all roles except product manager (or at times project manager) were constrained. This role holding the most authority in innovation enjoyed license to expand their role as desired, and to simultaneously reinforce other roles constraints.

Two issues draw from this finding. One, the role of product manager seems to be overly empowered by its lack of clear definition or boundaries. When no professional or organizational guidelines exist to mediate the work process for the role, actors in this role are more free to adapt the role to their personal motivations and aspirations. This leaves the other roles on the project team at risk for the effectiveness of their contribution, as they can be overruled at any time or even face having their key contributions to the decision process obviated by those using the product management role as a personal power base. Two, the organizational role of product managers is much less effective than organizations might expect. Senior managers should recognize that product management is an ambiguous management practice, and that the contributions of all team members add value to an innovative product.

This finding may be unique to software product innovation management. The literature shows a strong customer research focus in automotive and consumer product industries. The software products selected in this research embody very specific and technical functions not found in the consumer marketplace or on the Web. In an informed marketplace, bad feature decisions can break a product. In software, this has rarely been the case, which may allow this practice to continue until customers make their considerations known to software innovators.