Discussion of Case Findings

This research investigated the origination and meaning of values conflicts arising within innovation management in large organizations. Its implications revolve around the social and organizational impact of values differences on people, products, and organizations. The social impacts involve the appropriate use of power and the propagation of authority through processes in organizations. Organizational impacts involve the effectiveness of teams, projects, product design, and other outcomes of the organizational mission and strategy. Impacts on people range from the shifting of personal values to accommodate organizational values, to the strengthening of personal values and disavowment of values in conflict.

A discourse weaves through all the domains touched by this research – organizational values, structure, and process, product and project management, organizational culture, even the appropriate application of design methods. Consider two threads of discourse from the Findings. We find a direct story of the participants’ experience, and a meta-narrative of the organization’s context for constructing these experiences. The direct story draws from values conflicts experienced in the design process. The meta-narrative builds from interpretations about these conflicts, from the meaning given to interactions in the worklife ecology of organizational participants.

Case Analysis Summary

The survey of project process values suggests six dimensions contributing to values conflict. These process indicators, based on subjective ratings of actual project team activity, included three design process factors and three interpersonal behavior factors. The process factors showed extreme ratings of customer-orientation, requirements conflict, and design conflict resolution. The interpersonal factors showed team participation and task coordination were rated negatively.

The case analyses pointed to four core values conflicts encountered in software design processes. These claims point to values differences across the activities of innovation management. Participants considered the locus of conflict organizational, and not interpersonal, attributing their interpretations of conflict to the organization’s processes, culture, and goals. Further analysis showed other values conflicts with organizational values in-use, with development practices, innovation management processes, and between professional and organizational norms and values. As shown with other studies of organizational values (Argyris, 1992, Hinings, Thibault, Slack, and Kikulis 1996, and Katsioloudes, 1996), personal values may differ widely from espoused values embedded in organizational processes. Further, as espoused organizational values are found inconsistent with those in-use, individual conflict with espoused values arises. As Hinings et al (1996) offer, values underpin organizational culture, and shifts in structure must be accompanied by shifts in underlying values.

Every project case demonstrated some instances of conflict within project performance, in most cases expressed as differences in design preference or control of the product direction. Multiple conflicts typically occurred throughout the project’s development period, threatening team performance and project success. In some cases projects were canceled outright, and continued observation of the products released from these case projects indicate challenges in market share and acceptance. A formal performance assessment was not planned as part of the study.

Differences between espoused and in-use professional practices emerged as a source of values conflict. This finding was distinguished for both development practices and management process, two dimensions of organizational innovation management. Citing conflicts over appropriate use of authority, designers faulted product managers for failing to follow agreed practices, in essence “changing the rules of the game on the field.” Furthermore, designers often found official practices insufficient for product design, and expressed concern over their inability to migrate to practices using more robust design methods. Product managers sometimes described designers as following their own standards or approaches without regard to the needs of the product.

Without attempting to generalize from these indicators, experiential evidence shows these values orientations are typical and even expected within software organizations. Referring to the general software development literature, these cases represent the normal situation (Orlikowski, 1992, Poltrock and Grudin, 1994). In fact, the case studies in the literature that describe participatory project team behavior tend to be Scandinavian and not North American (Carmel, Whitaker, and George, 1993, Grudin, 1993), revealing a potential cultural difference. But the extreme ratings given most of these projects tell a different story – very few scores were assessed toward the middle of any of the dimensions, indicating a strong values response to the situation evaluated. Further, when aligning statements from the transcripted interviews with the survey findings, multiple examples of each situation are represented. Although these project cases were selected by participants due in part to their selecting cases in which they experienced conflict, the values issues are not isolated only to the selected projects. Values conflicts were identified at the executive, organizational, project, and team levels of every organization. Furthermore, the innovation management processes - project management, product management, the requirements process, and the design process – were affected.

Values Conflict in Innovation Projects

Innovation management brings together the urgency and complexity of new products, emerging technologies, uncertain competition, and unstable markets. With such extensive uncertainty in a business context, we should expect and normally find many types of conflict in the pursuit of customers, markets, and organizational goals. The values conflicts identified in the study show a deeper, more personal side to this normal chaotic hustle of the software product business. But organizations more than individuals bear continuing reminders of the legacy of conflicts. Conflicts affecting job satisfaction, career opportunities, team and organizational affinity, and project success result in serious consequences for the larger organization. When knowledgeable staff quit in frustration, and projects fail to deliver after misreading the customer, firms cannot maintain viability in the competitiveness of technology markets. Individuals move on, but the companies remain associated with reputations accrued from their turnover and many local stories spread by those that leave.

Software product development requires members from several disciplines to negotiate design and development activities, commonly leading to conflicts between professional approaches. Research participants ascribed such professional differences between project members as a primary source of conflict. Project demands force designers, developers, managers, and eventually even users to compromise professional values for the shared outcome of project completion. However, differences between practice values need not threaten product development to the extent found in these projects.

Values conflicts in knowledge-intensive projects were identified and analyzed from the ten project cases. The common conflicts were identified as team participation, cooperation, customer-orientation, task coordination, and requirements conflicts. These dimensions were evaluated based on a continuum ranging from open and participatory to authoritarian and closed. Cooperation was the only value not rated as authoritarian by participants. The evaluations indicated these values orientations mediated project activity and relationships within each project.

Pressing on this interpretation, practice values were further ascribed to cultural differences, wherein practice communities align themselves within their unique cultures. Practice or community identification often results in conflicts between approaches and values with members of other communities. In these project cases, practice conflicts were common between designers and software engineers, product managers and designers, and even project managers and product managers. This analysis finds consistency with research in professional practice from the sociology of knowledge, where members of collegial workgroups align knowledge claims homogeneously as a form of authority and a strategic response to power (Lazenga, 1992). The transcripts showed this response in action, as software designers interviewed noted power/values conflicts when their professional methods were dismissed in some projects by product managers. Their design practices were developed as homogenous approaches for product design and evaluation across the organization, and the practices promoted their expertise as a group, since no other groups were afforded use of their methods independently.

Embedded Power in Organizational Process Conflicts

Four types of process conflicts were found across the projects selected from the case organizations. In the organizational context these conflicts represent “distinctions of power” (Tsivacou, 1997), as the processes afford the “capability to impose intentionality on other organizational components” (1997, p. 27). Embedded power is revealed in these “operational distinctions” occurring from interactions in practice. Embedded  into processes and management practice, these distinctions are not typically recognized by organizational participants. The intentionality or power instead remains tacit, in Polanyi’s (1966) sense of losing the context when focusing on particulars. Embeddedness also draws from Polanyi’s supporting theory of hierarchical emergence; the higher level “controls the marginal conditions left indeterminate” by the lower levels. The “marginal conditions” show as opportunities or affordances for decision and use of individual authority. What the organization allows “up the hierarchy” will be enabled at the lower levels. As the affordances inherent in operational power are used over time, organizational components reinforce and maintain their relative advantages.

Role definitions, job and task expectations, chains of authority, and avenues of recourse are examples of embedded power that differ between levels of the organization. The role definition of “director” within a given organization contains these types of power without making the authority explicit at any time. Embedded, non-explicit power relationships that impact product innovation specifically include decision rights, the ability to enforce or dismiss process, to use or change design practices, to use or ignore information, and arbitrary design changes. These embedded power distinctions are more variable, since at times senior designers can overrule product managers, given a particular context. In some organizational cultures, professional expertise is afforded the embedded authority of its referent power. Embedded values refer to the organizational values inherent in these power distinctions, revealed by the conflicts that emerge in values conflict encounters. The embedded values of project management adopted within the organization incite many of the case projects’ conflicts between designers and product managers. When these values remain unquestioned, managers need only make a “product call” or sole decision to overrule the consensus of an entire project team. It is not only the aggressive usurping of design decisions that shows the embedded values; the moral outrage results from noticing the product managers never even question the impact of their unquestioned values on participation, cooperation, customer relationship, teamwork, or product vision.

The operational distinction of power maintains a powerful organizational context and identity based on use of the available power. The organizational function of investing power on those participating in product innovation offers a significant individual motivation for power as well. This discussion analyzes the function and impact of embedded power within the five process conflicts identified in the research.

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

A major theme of the findings was personal values conflicting with organizational values and uses of power in product design. Multiple conflicts were found in each defined case, and these conflicts were attributed to professional and organizational differences. A traditional organizational structure defined the environment for all project cases, and respondents cited substantial influence of hierarchy and top-down organizational process.

Three conflict types were defined from this finding: 1) professional orientation, performing as a professional, 2) professional ethics, conducting work appropriately, and 3) authority conflicts, e.g., confronting abuse of power for personal advancement.

This finding was pervasive, raising the question of whether this was “typical behavior.” Are values conflicts the normal course in these organizations? Or instead are distinct interactions occurring within project team situations, and with the creative and innovative work of product design and development? And even if this is typical, why should any organization consider a conflicted environment as acceptable, normal, or effective?

Although other researchers have shown the inevitability of project conflict (Curtis, Krasner, and Iscoe, 1988) which some consider healthy tension (Holtzblatt and Beyer, 1998), the interactions described here show management through power relationships and an organizational tendency to limit innovation. The transcripts reveal often demotivated individuals making the choice to cooperate in spite of values conflict. Observations also show these individuals leaving employment from the project environments researched, showing a trend of acting from personal values over organizational belonging.

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 conflict source in most cases. The two professional groups analyzed were product managers and system designers, but other viewpoints were solicited and recognized within the analysis. Across all cases, the organizational entities represented the following groups: upper management (vice-presidents and their direct reports), product management (business leaders for projects), software designers (user interface or software designers), technical (software engineers or other technical role), and users or customers. Therefore, we find product managers blaming designers for miscommunication, and designers blaming managers for thoughtless intervention.

Representations of software development organizational culture such as this are typical (Grudin, 1993, Walz, Elam, and Curtis, 1993) and these conflicts are presented within the context of existing knowledge. However, they establish the basis for values conflicts, as each professional group represented – product managers and system designers – responds from different values and priorities relevant to their work and worldviews.

When evaluating the causes of values conflicts, the common attribution of conflict was referred to as “cultural differences,” and different values orientations were then ascribed to these cultures. The norms and values of the professional communities of each organization were not specifically investigated, but they can be interpreted from the interview transcripts, since professional ethics and practice values were discussed. It was revealing that this distinction emerged from the representatives from both companies involved in the research.

Cultural differences within product organizations suggest the operation of technological frames of reference (Orlikowski, 1994), and organizational defensive routines (Argyris, 1992). The technological frames concept shows that practitioner groups share similar reference points about processes, and new work practices deployed across practitioner groups fail when they do not fit the preferred categories and traditions of these practitioner “subcultures.” New technologies have political implications, as do new work processes, and serve different practitioners unequally. Orlikowski’s (1994) study of Lotus Notes demonstrated that consultants in a professional services firm competed with one another for business, and would not use the new technology for sharing knowledge. Their “frames” were threatened by Notes, whereas the organization’s technologists treated Notes as a unique tool for advantage and promoted its use for firm communications.

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

Particularly in the design professions, research has noted the difficulty in establishing consistent or effective design practices within organizations not supporting a design ethic in the culture. Even in the case organizations, where Data Online maintained an existing product design department, members continually promoted the use of effective practices within their management chain, with only minimal acceptance of their processes. After 10 years of established human factors and design processes in the company, each organizational change threatened the continuation of the function within the organization. This seems a failure of institutionalization, defined by Berger and Luckman (1967) as the creation and perpetuation of enduring social groups. Persisting ten years throughout continual organizational change would appear sufficient for an institutional structure to achieve sedimentation (Eisenhardt, 1988), or the historical embedding of an activity. But researchers show how a group’s structural weaknesses make it vulnerable to replacement by more promising structures (Abrahamson, 1991). For a process to fully institutionalize, it must enjoy continued cultural support, management advocacy, and a high cost to change. When organizations restructure on a corporate scale, institutionalized processes can become vulnerable, as complete departments shift ownership, and new owners may not understand the purpose and history of processes.

Other research points to the effect of lock-in, whether technological (Lanier, 1997, Star and Ruhleder, 1994) or cultural (Perin, 1991, Zuboff, 1988). The cultural lock-in of practices relates to technological frames of reference (Orlikowski and Gash, 1994), wherein cognitions and values of organizational groups differ based on their shared frames. Orlikowski and Tyre (1994) further describe how “early interpretations” of technology use become embedded within work practices and routines, and therefore maintain influence. However, the cultures of the two case organizations seem to evade this embeddedness in the case of design practice. Although user interface design and usability evaluation practices had been used for many years at both companies, a consistent use of the practices was never supported by management. Whereas software engineering methods become embedded and routinized, to the point where software engineers may find new approaches difficult to adopt in practice, the design disciplines appear to be subject to different and variable rules.

A rival explanation may be found in organizational learning. Organizational defensive routines (Argyris, 1992) underlie dysfunctional behavior in situations where rational managers understand the explicit value of a work practices but continue to undercut them through authority or decisions. When effective work practices are dismissed or ignored, it may follow from their perceived misfit with the organization’s preferred categories and traditions. Design professional practice presents viewpoints that challenge the single position of power available to product, marketing, and business managers. Defensive routines show up in the case of offering explicit support to the design function, but implicitly avoiding its controversial aspects, such as feedback from the field that challenges the status quo or preferred product direction. New management processes introduced across organizational functions risk being dismissed quickly as failures, since their acceptance might require admitting the old processes were ineffective. If the status quo can successfully withstand new processes before they become institutionally embedded, those benefiting maintain their current advantages.

Differences between standard and practiced innovation processes afforded project conflict.

Innovation management requires the coordination of multiple processes in organizations for guidance of product development and management. In the case studies innovation management was defined as project management and project oversight, product lifecycle management, software development, and product/interface design.

Management process conflicts may stem from a common cultural issue within the organization also mediating design process conflicts. One key constraint affecting all participants was the traditional organizational structure, and the influence of hierarchy and top-down organizational process. The cultures of all case organizations also compartmentalized the sources of knowledge. Participants cited their structural separation from users or customers, from whom they derive task knowledge for design. This issue was tied to organizational “ownership” of customers, which remained an issue in all cases. However, there was little evidence to point to a central common issue mediating both management and design conflicts.. The conflict between espoused and in-use design practice appeared to stem from its threat to product manager power over the product’s features. The half-hearted use of official processes appears as a broader phenomenon, a shared sense of the affordances of the organization’s culture, which were driven more by the demands of the hierarchy than by official organizational processes.

In all case projects the standard and accepted design practices were either ignored or not used in full. Product and project managers acknowledged the value of design and innovation best practices such as usability evaluation or concept testing; however, most failed to use any “non-essential” practice on their projects. As noted in the Findings, participants said users and customers were the most reliable source of requirements and knowledge, but projects severely limited access to real customers. At times joint application design (JAD) sessions were employed, but only rarely, and on these case projects JAD was specifically used only once on one project. Participatory design methods were attempted on two projects, but found difficulty finding a receptive project team. Because these approaches were documented as standard practice, but were rarely used, the conflict appears between espoused and in-use practices.

As reported, most conflicts arose during requirements definition. This process is generally understood as the period in which product features are evaluated and selected for inclusion in a defined product version. In many cases, the initial requirements definition period serves as one of the first times a full project team convenes, so conflict is normal and can be expected. However, the underlying purposes and reasons for conflict differed among the cases. Four typical requirements process conflicts were identified:

• Conflict over management of the design process and practice selected for use.
  
• Professional differences with design decisions, especially with the decision process.
  
• Leadership conflicts, differences with the use of organizational or individual power in project and design decisions affecting requirements.
  
• Conflict expressed by designers about the validity or quality of requirements.

Requirements generated without any customer feedback were considered questionable. Furthermore, the requirements process itself was undisciplined in most projects, quality standards were nonexistent, and requirements documents were not subject to cross-disciplinary review.

Requirements conflicts in these cases further illustrate conflict between explicit, official design processes and implicit, situated design practices. Each organization supported official design processes with explicitly defined steps and methods. These processes were not necessarily followed formally, if at all. Situated, implicit design processes were typically used by designers, but were transparent, as enculturated professional knowledge (Blackler, 1995). That is, designers and developers described a design process they individually used as their approach toward daily professional practice, but was not codified by the organization. These practices should not be considered “informal,” in the sense of performed without rigor or skill, and they would also not be easily codified or shared outside the community of practice. These practices are best identified as highly skilled tacit knowledge (Polanyi, 1966).

The findings suggest that appropriate software design practices should be developed by those with the knowledge to propose the best-fit methods for the culture and the typical projects. Conflicts arise when managers seek to direct the work of professional practice, demanding not just a specific output but also the means of output. This demand on professional practice becomes a matter of contention and negotiation between practices and managers.

For example, designers in these cases declared their requirement for user feedback to ensure product design quality, Consistently, product managers demanded extremely rapid turnaround of work, and having control of the schedule and access to resources, schedule demand overruled the user feedback practice. Over time, these conflicts seem to erode the value of the professional communities’ practices, as members simply withdraw from confrontation to avoid conflict. In some organizations within this study I observed the decline of professional skills and state-of-the-art methods, as professionals stopped maintaining currency due to the frustration over the sanctioning of their work methods. The larger organizations appeared to value project cooperation over expertise - the work life of these professionals was made less frustrating by “going along” with conditions rather than pursuing professional development.

Process conflicts interfered with team knowledge integration.

Knowledge integration is an important activity supported by product innovation teams. All software teams intensively generate and then learn and integrate learning and knowledge about the design’s subject domain. Team integration of appropriate knowledge is considered necessary for successful software design, by constructing shared models of the problem area (Walz, Elam, and Curtis, 1993).

Several potential barriers to knowledge integration were identified. Members of different organizations held multiple goals and values that conflicted, changing the focus of interest and learning on teams. Product managers and designers held differing frames of reference toward design that, if not resolved early in the project, tended to polarize. Also, as team leaders overly directed product design activities during learning and knowledge integration, team members were unable to collaborate freely in exploring alternatives and innovative design approaches.

Control of the project became a significant obstacle to learning; some project leaders directed project activities and changed requirements without the knowledge, feedback, or interaction of other team members. Decisions and knowledge were unavailable across the team, leading to unproductive courses of action and incomplete shared understandings. Furthermore, the covert management of the project and product diminished the motivation and involvement of designers and other team members. Unilateral revisions of the product, made “behind the scenes,” communicate the message that research and design activities make no difference. Knowledge integration will remain incomplete in these situations. Finally, schedule demands also attenuate knowledge integration, as an aggressive deadline restricts the freedom to learn the domain and prevents gathering adequate user feedback.

In the literature, knowledge integration shows up as central to the product design process. The sharing and integration of project-specific knowledge among team members also emerges as a theme throughout the transcripts. Development teams learning a domain integrate knowledge from numerous informal interactions during design, creating a shared understanding and team memory.

The cognitive overload experienced by those engaged in knowledge integration explains why teams may ignore new methods or processes that might effectively serve the project. While intensively learning about the domain, requirements, customer needs, and development approaches for a complex system, team members ignore information not directly relevant to their frames of knowledge. Walz, Elam, and Curtis (1993) underscore the need for integrating through iterations of “design bites.” They found designers were “only capable of integrating a design bite’s worth of information into their current understanding of the design task, based on the ability of the new information to ‘attach’ to that already integrated into the design” (1993, p. 71).

However, this would only explain the ignoring of practices brought forth during later in requirements or in early design – in order to be used on projects, new design practices must often be proposed during the project planning period. Design and evaluation activities require time for learning, performance, discussion, and integration. Therefore, they must be built into the project schedule in advance of project kickoff, if possible.

Also, design and evaluation practices specifically aid the team in deeper understanding of the problem domain. If they become integrated into the schedule, they actually serve the team’s knowledge integration by providing relevant contextual information at the point of need. For this reason, such activities are often desired by the team members, even if dismissed by project or product managers.

Not all software development requires the extensive sharing of knowledge in developing a common framework of the domain. However, for products complex enough to require large development teams and half-year or longer development cycles, knowledge sharing remains a critical learning and performance function. Teams that split important learning across team members risk building on assumptions not shared by the whole team.

Affordances for Resolution

A central concept from the interpretive study was that of the organization as an ecological environment, hosting a dynamic network of social “affordances” for individual interaction with the network. Social affordances are perceptible factors (recognized points, opportunities, allowable conditions) available in social environments that offer situations for meaningful action to interested actors. By offering perceptible information in the social context, affordances let actors pursue intended paths of action through typical interactions in the organizational environment.

Conflicts and breakdowns offer time-dependent points in which some resolution must take place. In the case studies, process values were identified from the project context, their point of conflict. In these organizations the values conflicts reflected points in product design and development where conflicts typically arise.

Analysis of values conflict across case projects describes several factors, such as the most common conflict types, the values represented in the conflict, the timing of conflict situations, the organizational relationships involved, and the professional practices involved. This research pointed to many conflict incidents occurring in requirements definition, or in early design during iterations of the user interface. These are points where team inputs to requirements and design rationale are discussed and design decisions are made. Other values conflict points co-occur with normal team interactions, such as when initial team roles and responsibilities are claimed, or during high-pressure periods such as testing and release. Given product managers and designers, we would expect conflicts to occur primarily within requirements and initial product design.

Analysis of organizational conflict points should evaluate the larger scale institutional processes, such as product development, market research, customer service, or product release. Although this research investigated values embedded in organizational processes, it did not specifically address the conflict points at this scale of interaction.

In other research these conflict points are described as encounters or breakpoints, which offer the opportunity to reflect on effective process and suggest or lead changes. Robey and Newman (1996) identified how “encounters” punctuate design and development over a long-term project. Encounters are accepted and established points in time where organizational members meet and expect to make decisions or review contributions. Some encounters are designed into the innovation process, such as formal design and review sessions and technical walkthroughs. Other encounters arise as required by the project or management. Robey and Newman identify encounters as “opportunities for actors to challenge established practices” (1996, p. 33). Effective innovation processes might deliberately build in multiple encounter points within projects and organizational interaction to enable teams to review their practices and legitimately question their approaches.

Case study research and literature in social systems design point to typical conflict points in the design and development process. These points of conflict can be associated with values conflict to make a case for resolving points of values contention; however, these points exhibit variation by process type and show differences within organizations, just as with individuals.

To further this analysis and discussion, two innovation management processes were analyzed, specifying the points and types of values conflicts as found through case research and empirical observation. These two processes, systems design and project management, were defined as generally as possible to classify a larger set of observations, and to distinguish between the two processes.

Table 4-5. Values conflict points in a systems design lifecycle.

Following a classical lifecycle model for systems/product design, six categories classify the activities and intentions for each stage in the process. This model identifies types of conflicts that occur within system design and development, as found in the engineering development paradigm. These points of conflict primarily from the decisions necessary in defining buildable products and resolving ambiguity in the engineering process. Values considerations also emerge from these same reference points – at the each point of decision, managers are faced with customer values, values of the product owners, design values, and engineering values.

To simplify decision making, structured processes often ignore these potentially contentious resolutions. Project management (PM) approaches are often used as a means of distancing constituents from these considerations – decisions instead are made by authority and not participation, under an assumed shared value of “moving the project forward.” The project management process (Table 4-6) identifies the values conflicts afforded by PM, a discipline that embeds values that are rarely critiqued. Project management maintains economically-based values in its emphasis on controlling projects and other management commitments to maximize progress against both time and cost measures.

Other paradigms for software product development should be considered in a complete analysis of values conflict resolution points. The chosen design processes and structures define the encounter points where conflict occurs, as well as the types of decisions made. Although a generic product development model was analyzed in Table 5-1, a similar scheme could be constructed for participatory design, architectural design, social systems design, or information systems development.

Recognizing the opportunity for fruitful resolution of natural conflicts in design, Leven and Stolterman (1992) pointed to the design solution or “vision” as an affordance for resolution. Observing what appears to be a natural bias of skilled designers, in which an “ideal solution” is envisioned very early in the design process, Stolterman asserts that this tendency should be supported by the process. “Design methods should instead consider the possibility to exploit the natural behavior of system designers. A design method should inspire designers to bring forward their visions, to compare them and use them as design technique, ands to make this happen before the traditional analytical work begins” (1992, p. 8). Preventing conflict between the initial vision and the results of analysis supports the rationality of design, by allowing the preferred response of designers to contribute to the design rationale along with the necessary traditional analysis.

Project processes are defined from the Project Management Body of Knowledge (PMBOK), (2000, Project Management Institute). The PMBOK model enjoys significant consensus among project management professionals, representing the aggregated professional practices from the professional society that certifies project managers. The values conflicts in this process model are described in the context of the problems of project management, and are not specific to software or product design.

Table 4-6. Values conflict points in the project management lifecycle.

Project management practice assumes a values system of schedule efficiency, cost effectiveness, and strict management to specifications. Project management training and practice hold project completion as the most significant operational value, but project managers between industries (software and construction, for example) also bring different values systems inherent to their industry. Project Management is considered by many practitioners to be a values-neutral discipline that supports its customer requirements through disinterested and professional management of project requirements. However, its interests are noted in the practice – project completion, schedule, cost, and the other related values defined in the nine areas of the PMBOK clearly distinguish a guiding set of values used to direct action and choose among alternative options.

Project management values can be distinguished in the standards of developing and meeting schedules, budgets, and quality criteria for an agreed scope of work. Furthermore, project managers make values-based decisions daily within the execution and control of a project. Some of the typical value judgments include:

• Which team members are selected for leadership, and the criteria for selection.
  

• Which team roles are given priority in decision making and schedule influence.
  

• The process and participation allowed in decision-making.  
  

• Contingency planning and identifying types of risk.Management style and approach, team attitude and allowance of individual expression.
  

•  The “orders of abandonment” during crisis, the identification of problems, and their representation to management.

Although project management is perhaps necessary for project fulfillment, is it sufficient by itself? Does “good project management” address any of the organizational conflicts discussed in this chapter? Or does it serve to diminish awareness of other values and submerge conflicts?

How do the values of project management impact organizational dynamics? PM practice focuses organizational commitment onto the defined scope of a project. Project team leaders and members are continually “reminded” of the priorities of scope, schedule, and cost through project management. Perhaps no other role in product innovation presents its values litany so clearly and repeatedly. No research shows the extent to which this “reminding” practice has diffused among project managers. However, observations as a consultant and team member across numerous projects support the claim that this expression of project values persists and remains unquestioned. It is perhaps one of the most effective tools for gaining allegiance to the project goals, through sharing the cost and schedule goals with the entire team. Although project managers are held accountable to these values as metrics, they in turn hold team performers accountable for meeting their portions of the project. Using other incentives, such as team bonuses, and disincentives, such as overtime without pay, project managers push the project values into daily discourse as a purpose and goal for the entire project team.

Some research has shown differences in interests and values of project managers in innovation and information technology environments, so these orientations should not be proposed as general. Tractinsky and Jarvenpaa (1995) evaluated values differences for global and domestic (geographically-specific) project managers in IT. Significant agreement was found among all project managers for the importance of decision making and control in projects, with economic issues ranking toward the middle and cultural diversity and balance of power ranking universally low in importance. These values stem directly from the requirements of the project management role, and suggest a common adherence to a management paradigm of rational decision making and central project control.

More experienced project managers, found in the “global” group, expressed sensitivity to social and work practice requirements and to cultural alignment. The domestic managers were more likely to focus on technical needs to the exclusion of social factors. Recommendations suggested the need to educate project managers more broadly in global and international issues, to increase their awareness of broader corporate and social impact.

The inherent values of project management are unlikely to change – the whole point of PM is its extreme focus on the task, to manage the project as a corporate priority. If project management incorporated more consideration for important but overlooked values, the power of PM could be increased to the positive benefit of all stakeholders. As experienced project managers observe the value of integrating the social dimension, their support of the social and human perspective will enhance worklife, motivation, and participation within the team. Over the course of multiple projects, the positive experience of participants would grow, influencing professional communities of practice. Project management might offer a place to start for developing an organizational culture of participation and learning.

Following Robey and Newman (1996) these points of conflict described in systems design and project management might be termed “values conflict encounters.” Encounters are situations where coordinated groups review and discuss process as well as tasks during milestone events or established meetings. In encounters, organizational conditions allow expression of normal conflicts of professional and task roles. Since encounters also afford review of process issues, these points should be identified within organizations as occasions for process critique, thereby allowing discussion and resolution of differences. Encounters might be further enhanced by explicitly discussing rationale, by posing “why” questions about process, product, and policy.

Following the Ten Innovation Projects

In spite of the cited management issues and constraints imposed by official process, most projects were finished. Six of ten projects were completed, yet all ten were characterized by project conflict. However, four projects had been canceled outright, and several projects have fared poorly in the marketplace.

All of the projects had been planned and staffed as high-priority, funded efforts, considered critical to corporate strategy. Interpretive organizational research does not offer all the tools necessary to surmise the factors contributing to successful or even eventual project completion from these cases. Without a research focus on strategy, management, the customer’s marketplace, and project management, it would be impossible to qualify this finding as related to any of the conflict factors studied.

Although completed, these projects were not all marketplace successes. Product success in the marketplace remains an issue not explored in the analysis. But the findings pointing to the disuse and misuse of customer research in many of the projects would indicate the projects were not informed adequately by customer data. For example, the Web Enterprise project documented in the findings suffered the explicit rejection of hard-won customer data by the product manager. Although critical to the company’s strategy, it was never received in the marketplace, and its design continues to be reworked even two years after the research interviews. Some of the original first-generation Web-based products described in the interviews have been pulled from the market, with new offerings integrating some of their functions. Two years later, we can look back at both the completion and the market reception of these products.

Don – Infrastructure project: Since this was internal, and not a market product, few developers were available to work with this complex legacy system. Participant left the company in 1999, and work continues on this project in various forms.

Paul – SearchBuddy: This product line was designed to meet a specific need, but was never integrated into a broader offering or met sales goals. This participant left the company recently, over five years after this project was finished.

Jack – Reference Infrastructure: This project was cancelled before development. The managers have all moved on or left, the product manager participants moved to a different job.

Lynne – SalesView: This project had struggled throughout its existence to provide a baseline offering to the market. The product never made it to the Web as planned, and the product will be retired following a final release.

Brian – Web Enterprise project: This project suffers in the marketplace after three or more years of redesigns and changing staff. The original participant interviewed changed roles to be the fourth product manager, and has revived his original vision for the product based on the defined customer need.

Hal – Data Improvements: A collection of projects associated with this interview were well-received by customers and gain share in the marketplace. Note that no conflicts were identified by this participant, who, among all those interviewed, retains his original role.

Karen – Web News: A collection of Web-based search products that suffered from management changes. These products were completed, albeit released late, and have since been reintegrated within other offerings with new identities. This participant left the company in late 1999.

Lloyd – Online Science project: This product was received well by the marketplace and by users, and has overtaken all competition to lead market share. This product was released on time and very close to the design evaluated by field users. The product manager left the company, and the original managers moved on via promotions.

Mike – WIP project: This project was a critical partnership between existing product lines, and was extensively user tested. However, it was recently cancelled and the participant left the company.

Kent – CAD/CAM project: This project, although an older effort, failed internally even when its sponsoring organization required its completion. The participant had left the company before the interview, and the company continues with its reputation.