Autoline Data Systems

Context

Autoline was an early leader in their market, as a vendor of integrated management systems in the automotive industry, and had branched to other markets. Having locked-in the early market, their established product line was sufficient to generate profits and maintain market share. As competitors gained ground in the early 1980’s, the company was forced to innovate, but having grown from a business-oriented culture, creative innovation and risk-taking were not among their corporate organizational values.

Marketing and sales executives historically made product decisions in this company, and their influence remains strong in the culture, even though the company has instituted a business-based product management organization. Software product engineering at this firm is managed by cross-functional integrated teams led by product managers, but balanced with software, service, and other specialists. The team approach has become successfully integrated into the culture, and project team members typically remain dedicated to products for the lifecycles of several release versions.

The company has grown in size and has successfully defended its market share from several traditional competitors as well as emerging Internet competitors. More recently through growth, new managers have been hired from other product companies and some have attempted to sponsor new organizational processes. However, in-house methodologies have been the most successful of the product processes. The product management process has been institutionalized and used productively for over five years by almost all project teams. Very few differences are apparent between the official processes and in-use practices – most project teams actually use the official process, and do not innovate with new methods or attempt to improve the process with informal variations.

The participants in the research had worked for more than ten years with the company, and had somewhat similar professional backgrounds. The primary participant filled the role of a product manager, essentially a line manager with responsibility for product planning for a mainstream product line. Her professional background also included instructional development, service management, and human factors. The other participant was a product manager for other product lines in the company.

Organizational innovation processes

Eight processes were identified for Autoline Data in use between 1993 and 1999. All processes except one were officially deployed throughout the organization, and these seven were also mandated by management. Organizational management owned all official processes. Two of these processes were organizational or human resources, so only six compare to Data Online.

Table 5-3. Organizational processes in innovation management – Autoline Data Systems.

Only one process can be considered a community practice with a local values focus, the Human Factors/Design process. Management initially supported this process, but did not provide organizational support for the required competencies or promote its usage. The PSP requirements process was adopted for three years by most projects using the P3 framework. PSP fell into disuse as a requirements process, though remaining the “official” practice. Although the requirements prototyping component of the Human Factors process was designed to replace PSP, neither practice is effectively in active use. No replacements are planned, although product managers across the company continue to express their need for requirements and design practices in development projects.

Recent observations of this organization show a continuing pattern. In 1999 an executive individually established a replacement for Product Management, using the process committee role. The replacement process was diffused as an official business process, but managers interviewed (post hoc) received it with skepticism. This replacement process was excluded from analysis as it was unavailable to participants during data collection.

Organizational affordances for innovation management processes

The company’s organizational culture was not supportive of “formal methodologies.” In this firm it was “typical to rollout or manage only one process at a time.” However, methodologies of long-lasting value had been integrated thoroughly into this organization, unlike Data Online.

Organizational adoption and widespread usage has been achieved with product management / lifecycle processes. Unprecedented product delivery results had been achieved with the P3 product lifecycle process. Before P3, the company had not previously relied on business processes for product lifecycle management – traditionally the product teams had lots of autonomy, and were able to manage development in any way that suited the team.

Acceptance of P3 spread in use among projects after user reported its results in practice. Its benefits were reported as not having to redesign (churn) on major development efforts, increased customer satisfaction ratings with delivered products, and the value of deploying a consistent shared vocabulary across the organization. Success was perceived from having gone from nothing (no process) to something, being a practical management process considered sufficient and meaningful to the organization.

The organizational affordances for adopting the P3 lifecycle process emerged over the first 4-5 years of its use. These were found as: 1) a recognized need was acknowledged for a consistent process for product management, 2) the organization faced significant product delivery goals the processes addressed and guided, 3) the process was enculturated with coaching, training, several types of documentation, and support, and 4) product teams recognized its value and defended the use of the methods when under reorganization threat by new management.

Cultural integration of organizational processes

Organizational assimilation of the P3 lifecycle process was supported by instructor-led training and a team of coaches available to the product teams. People initially expressed apprehension toward using the process, as developers and others without prior experience with standard procedures expressed initial discomfort. They had no skill in the recommended methods and techniques, and were concerned for the burden of adopting such a large change in daily work. P3 gradually became used as a “process infrastructure” for product management guidance. Its enculturation as a shared system enabled organizational learning – those learning the lifecycle process became better able to plan projects and predict development consequences, made more rational date estimates, and met product goals more reliably.

Other management processes were introduced in Autoline Data, with most new processes introduced in the period from 1995-1999. This period corresponded with rapid company growth, and with it came an influx of new managers from outside the culture, bringing their own practices to the organization. Some of the new managers did not assess the culture to understand how to best fit or accommodate the practices from their experience as new processes into this organization.

Initiatives generated from outside the culture failed to take hold, since the organization was not “ready.” However, readiness should be recognized as relative to the culture. An organization will never be “ready” even for simple practices if they are not adapted to the values and organizational mythologies pre-existing in the culture. To some extent, this asserts that cultural change cannot occur from outside the culture, but only from starting with the cultural values and mythologies that people identify with already. Once accepted nominally into the culture, substantially new practices can be introduced effectively. This occurred after P3 was fully adopted – several new practices, including a complex requirements methodology – were integrated into P3 and used throughout the organization overall.

Constituting spin-off culture – separation of norms and practices

Within Autoline Data a new software product organization had been established to develop a separate product line. In effect, this organization created a separate culture, abandoning all institutionalized processes from the larger organization. The product management team instituted their own, alternative, product design process. Managers and analysts developed their own specific practices, many adapted from the components of other processes. Using an organic approach, they proceeded through multiple iterations (trial and error) and refrained from formalizing the practices. Instead, they were embedded in project management and design practices used as repeatable activities by intact project teams. They experimented with process variations, joined with design expertise available from local design professionals, and evolved approaches that served the requirements of their unique project.

An illustrative example of the effectiveness of their management approach was found in the project’s approach to knowledge creation. If managers felt skill in a desired discipline was necessary, instead of attempting to gain sufficient knowledge with the current staff, they strategically hired experts in the disciplines required. They then supported the newly hired expert to develop appropriate practices that fit their organization and project. Overall, their process management approach was conducted informally, but learning and knowledge were shared throughout the group officially and informally. Design and development practices were not formally codified, but a close-knit team of product analysts, designers, and software engineers effectively followed the local practices.

Observers of this approach recognized the usefulness of developing the processes more formally following a period of intensive local use by such a project team. By leveraging an organizational affordance, such as the initial product release, a process team would serve this need by integrating the practices into a codified methodology, based on learning and usage in actual product development. This bottom-up approach would result in a custom-tailored methodology with total organizational adoption from its inception. A caution drawn from the previous findings would be to maintain an informal process committee, and not to endow it with organizational authority. In hierarchically-oriented cultures , such committees can grow into power bases, effectively preventing organizational learning and expertise development.

Patterns of organizational process failure

Unsuccessful organizational processes followed a different pattern in Autoline Data. A management initiative to sponsor a process for organizational goal-setting encountered significant difficulty when it failed to take hold in the ranks. The “Line of Sight” (LOS) process was adopted from Xerox by a group of new executives with prior successful experience with the process. The vice-presidents deployed the initiative themselves and pushed it broadly across the organization. However, the LOS process focused goal-setting solely at the executive level, and did not propagate goals at the product and project team level. No process champion or facilitator had been engaged, and the executives failed to provide any coaching, teaching, or support for learning the process. This left the initiative hanging between organizational levels, as the executives pushed the process “from the top,” and left it to middle managers to handle the details. Middle managers were lost in the new process – they did not perceive any clear roles for themselves, and found no support for fulfilling the process within their departments, and dialogue between management and staff levels broke down. The VPs and others had invested heavily in the process, and after it failed, most new “process initiatives” introduced by VPs were met with skepticism.

Necessity for affordances supporting new practices

A similar situation occurred with a human resources process known as the Organizational Climate Survey, which was widely adopted before trailing off into disuse. This process was initially structured as a standard HR survey of organizational conditions and enabled the opportunity for associates to recommend improvements. Following similar popular approaches deployed by HR in recent years, this process distributed surveys across the entire organization, and followed up within departments with focus groups facilitated by HR staff. Typically, associates participated in these sessions with their managers absent, and were encouraged to identify organizational issues and bring forth recommendations to address conditions.

The objective of the Climate Survey was to “empower” associates in organizational development and improvement. On the surface, this seemed a worthy effort by management to involve staff and associates in defining critical workplace issues and recommending workable approaches for managing the issues. A flaw in deploying the Climate Survey was considered that associates had no real authority to sponsor organizational changes, even given the official communication that they were “empowered” to target needed improvements. Autoline Data ’s organizational culture into which this initiative was deployed was hierarchical and risk-averse, so associates did not perceive affordances for their empowerment. They would have been required to ignore hierarchy and take personal risks on organizational initiatives, and these were actions without relationship to their jobs or rewards.

The associates encountered mixed messages and contradictions in this process – they felt that executives should be accountable for organizational development, and while the executives talked about “empowerment,” they never really “gave away” the authority or power to make anything happen. Eventually, the process dropped down from the highly visible HR facilitated sessions, to a mailed-in survey, and finally to a scaled-down survey emailed to associates.

Organizational process interdependency

The project management (PM) process also incurred mixed results. It represented a process initially developed with little regard for the existing culture, and was finally integrated with P3 once affordances were established for its practices. The tools of project management – scheduling, PM software, project controls – conflicted with the prevailing management culture of “working to the dates.” The PM process was rolled out before the P3 product lifecycle process, a poorly-timed sequence not recognized as such at the time. Since the culture had not learned from using an instituted product management process, teams and managers were not prepared for the disciplines of work breakdown planning, rigorous task scheduling, critical path estimation, and other PM tools. These methods and the formalist approach to projects showed up as a cultural mismatch; project leaders initially distrusted the use of a standard WBS, the highly complex planning software was seen as unwieldy and too sophisticated for their projects, and the project control discipline required was viewed as an additional burden.

Cultural issues with process

The PM process encountered difficulty for the first two years even fully invested with technical support and management backing, two factors lacking in both the LOS and Climate Survey. A training staff was available for diffusing the methods and offering team coaching, and the need for project discipline was widely acknowledged. The issues at fault with project management may have been more rooted in cultural values conflicts and the lack of context for practicing PM in the organization. The prevailing management values respected date-based project goals and executive control of time-to-market decisions. This directly conflicted with the discipline of planning projects based on analysis and estimating dates based on resources, an orientation requiring management to relinquish some power over projects. Also, the software package initially installed to support project management (PX) was sophisticated, more suited for complex military product teams instead of an “action-oriented” commercial software vendor.

Shared values change gradually – and methods easily fall into disuse in product organizations if managers fail to support them. Eventually, the organizational culture embraced the lifecycle processes of Product Management and P3, creating an affordance for project management as a supporting practice. The tools adopted by the time of acceptance were more informal – Microsoft Project was installed as a common tool, replacing the PX package in general organizational use. Some of the WBS work was recycled into standard templates available to projects as draft task planning structures, without the sophistication inherent in the original process as designed.

Innovation management by process committee

How do we know when sufficient context has been created for affording new practices? The original P3 process had prepared a series of simplified templates for product lifecycle management, similar in intent to the LBMS templates deployed by Data Online. These templates represented the various software and product lifecycles typical of the projects currently performed by the organization, as well as more advanced lifecycles (e.g., spiral and incremental) that were strongly recommended to the organization during a consulting study. When P3 was rolled out, the process committee had collapsed these lifecycles into just a single template that included all the tasks covered across all templates. This lifecycle model essentially offered only the traditional (and insufficient) “waterfall” lifecycle - the model P3 planners had originally intended to replace in use by developers and product managers.

The lifecycle models were specifically designed to be integrated into the organization – they had been included in classroom instruction to all software developers and managers in advance of P3 rollout, and they were based on industry standard representations. They were simplified and used Autoline Data standard terms, and matched the WBS activities prepared by the project management support team. However, the lifecycles were not even made available to advanced product teams, and were withheld from the process documentation.

This may not seem like a significant action; but what were the net effects? The decision of a process committee to support an inadequate lifecycle model (waterfall) and to oppose other approaches stifled project management innovation. Essentially, these decisions had prevented the entire organization from adopting iterative and incremental development methods in the organization. These approaches have been used by most software product organizations over the last decade, and have even become military standard. The exclusion of these development lifecycles from organizational practice may have also contributed to diminishing competitiveness and even product delays.

Observations on process deployment

What lies behind the decision to withhold support for the full set of lifecycles and to deskill software development? The research interpretation was that the P3 and coaching committee was unprepared to support these other lifecycles if used in the organization; they had no direct experience using any model than the traditional waterfall themselves. Supporting the five other lifecycles would have required consulting with projects on the proper use of them, explaining them in training, and ensuring the models were adapted for appropriate project types. This would have incurred risk, and required learning and experimentation on the part of the committee. Risk and experimentation were not inherent values in the culture or the committee. Since there was no affordance for using the lifecycle models, and the risk-averse culture did not reward experimentation with new methods, the models were selected for exclusion.

Few technical advances were made with either Product Management or P3 since their rollout, although the basic practices were further refined. So although additional research had been performed by product teams for advancing (and simplifying) the requirements definition and product design methods, these practices stopped at the process committee. After these methods were trialed successfully within innovative product teams, the innovations developed by these teams were not offered to other projects, even acknowledging their proven value. A rationale for this, based on the context of prior interpretations and historical evidence, was that the management committee chose to maintain a status quo that offered a predictable value and level of process support. The committee had not expressed interest in innovation themselves, but when product teams offered their learning and recommended methods for inclusion and broader organizational learning, these methods were dismissed or included in weaker form.

Variations of these values were apparent in Data Online in several cases. In one example, the CMM process rejected three known proposals to include requirements definition practices. Innovative product teams developed and refined these practices using small groups of experts and working across the organization. The innovations were based on actual experience and learning by using the requirements methods successfully in projects. Instead, the CMM managers indicated the innovations were beyond the organization’s current abilities, believing the organization should “walk before they could run.” The committee published guidelines of abstract standard templates for requirements methods representing a status quo approach.

Management interventions affecting culture and process

The other major impacts on the adoption of organizational processes were consistently and recurrently identified as reorganization and management transitions. During these transition periods, support for existing processes often drifts, and associates and managers – for several reasons – stop using the routines. Staff abated their process usage for several reasons: 1) management no longer required use of recognized processes during the transition, 2) during organizational uncertainty, people spend time only on primary work routines, knowing that workarounds and simplifications are now sanctioned, 3) management no longer rewarded employees for following processes, since their own accountabilities had changed, and new responsibilities might be based on different processes.

Perhaps the most compelling concern was employees recognizing how the new management might dismantle processes, since that had happened frequently in the past. Only “proven,” widely-used, and robust organizational processes can survive such attitudes and history. If management transitions continue to support the historical processes, an organization will find it difficult to establish new processes, regardless of their presumed value. A pattern is suggested whereby a mediocre but well-known organizational process will survive the attempts of management to replace it with new (and even greatly improved) processes. This pattern would have implications for developing more effective new practices, when designers are faced with replacing an existing known practice with one shrouded in uncertainty and risk.

Management intervention was considered a significant threat to deploying new or revised product processes. Managers unfamiliar with an organization and its practices often disregard or misunderstand the value of existing practices, or considered processes to represent needless overhead. Similarly, this threat occurred when executives installed their own processes, and disposed the existing ones, disregarding the difficulties of enculturating a new process. The management replacement of workable practices with arbitrary routines selected for “ownership” was seen as causing substantial harm to work practices and professional identity.

Process management gatekeeping

Autoline Data fostered few alternative innovation management processes and methods, being an action-oriented culture that did not reward intellectual efforts. One initiative designed to establish alternative design practices for the P3 process met with mixed results. Based on industry standard human factors design and usability methods, the design process initiative addressed the need for involving customers in product requirements and design. Developed by product specialists at the project level, who had both interest and some human factors backgrounds, these practices were tested, refined, and documented over the course of a 9 month period. The practices fully addressed the methods for product definition, requirements gathering, prototyping, and user evaluation. Even as these documented practices were formally presented to the PM committee in fully documented form, and were discussed at numerous times with committee leaders, the practices were never integrated within the official process documentation. Because the committee leaders never sanctioned them, the larger organization was in effect denied the opportunity to use them. Even with specific executive support offered for these practices, they never gained a solid organizational foothold.

These observations reveal how institutionalized organizational processes become stabilized and then serve to maintain the status quo. If specific groups are formally established to maintain processes, such as when process committees are formed to evaluate and approve best practices, the level of participation across organizational communities drops off, or is even discouraged. Process committees both case companies formed agendas consistent with maintaining processes and implementing tools to further formalize and structure the recommended practices. This level of format structure was seen as inhibiting further learning and improvement of practice in communities requiring skill development. As with Data Online, once processes and their committees were established, the chair and members gain prestige and authority by “policing” the process. Although this may serve to legitimize the process and its value to senior managers, the committees can easily and typically defeat the very purpose for their establishment. The formal process organizations or committees can squelch the participation of skilled professionals in process improvement, and prevent the unique contributions of practice groups from advancing the innovation process.

Organizational learning and defenses in process management

Overall the organization seemed to learn from its visible failures in organizational process. During the mid-1990’s, new organizational processes were reportedly introduced on a “monthly basis,” an exaggeration reflecting the organizational fatigue with new process initiatives. This proliferation of new processes maintained staff in a continual state of both learning and uncertainty, as members were unsure of the intention and use of the new practices being asked of them. Following two highly visible process failures, the organization evidenced more circumspection and deliberation upon the introduction of any new organizational process, suggesting an expected state of skepticism. New process initiatives have been deployed infrequently since these process deployment failures.

As typical in traditional organizational cultures, people generally responded to new processes with single-loop learning at best. When problems occurred in the complexity of learning a new practice, teams addressed the learning curve of the process and incurred significant delays and problems. For example, a project team contributing to the study identified schedule and requirements issues resulting from using recommended requirements methods associated with the PM process, specifically the PSP practice. Even though this team was considered among the most advanced in software development capabilities and use of methods, they were unable to make time to revise the process to better suit their needs. They had made recommendations to the process committee for adjustments to the PM process, but the process committee neglected these provisions. The PM process remained somewhat static since its rollout, and changes were made to its methods on an infrequent basis.

Overall, the process committee appeared unable to integrate feedback from the use of processes, and did not learn to adapt the methods to actual product management practice. They also seemed unable to integrate or perhaps recognize the value of new knowledge that might significantly improve the process. In numerous interactions, the assertions from the committee members indicated they believed the organization unwilling or not ready to assimilate more sophisticated methods. They performed a gatekeeping function, allowing very little new knowledge into the supported process, at least at the “official” level of process management.

One perception of this official gatekeeping and unwillingness to advance the P3 process was that the new knowledge – already researched, documented, and formatted for integration into P3 templates – threatened the organizational balance of power held by the committee itself. Specifically, a product team developing alternative requirements practices documented their approach and found significant cost and quality benefits to the new practice. They submitted a comparison of practices to the committee chair, but this report was never adopted, supported, or even discussed. When presented to two sponsoring vice-presidents, they fully supported the findings and verbally supported the inclusion of the practices into P3. However, more than a year later, after some other revisions to the P3 process were released, none of the recommended practices were included or otherwise officially published.

Conflict between local practice and official process

In this case, all of the usual recommendations for diffusing “best practices” found in both the popular and academic business literature were followed, and they were still blocked by prevailing forces in the organizational culture. Specifically, the design and requirements process improvements were fully developed based on industry standards and state-of-the-practice methods. The local practices were developed using an iterative process; simple methods were piloted within real projects, the lessons learned from the pilots were reviewed, and the process was further tailored to fit into the prevailing Product Management lifecycle process. The final pilot process was integrated into templates and examples with supporting documentation, and supported by research citations. Two pilot projects had both local and executive management support, after several educational and status presentations. The sponsors stated their support publicly, and advised continuance of the process. Training and coaching were available for other interested projects. In summary, every known type of process support was employed, yet members of the process committee apparently blocked these practices. The committee was, of course, responsible for the initial process the new findings were perceived as potentially replacing. These situations suggest that process committees should not be officially sanctioned as organizational groups, due to the high potential for conflict of interest for accepting the advancement of organizational knowledge creation.

As similar to Data Online, this situation manifested following the institutionalization of a process and the founding of a committee with a designated head. The official deployment of a product lifecycle management process appears to create a platform for boundary-spanning organizational power. The affordance for authority shows up as when part-time or full-time staff members are charged with maintaining and supporting the process across the organization. When process managers and not the process users coordinate a pivotal function for knowledge coordination, the opportunity arises to use the position for organizational power and control over work practice. Innovation management processes coordinate activities among multiple projects and product, investing role designations, staff responsibilities, dependencies, management reporting relationships, budget authority, and quality criteria for identifying “successful” and “failing” projects. Setting organizational criteria and promoting the process to management becomes a large part of the process manager’s job. Establishing a formal organization to coordinate innovation processes may centralize too much power over work practices; this suggests the effectiveness of a participatory model for process management.

The defensive postures exhibited by organizational process authorities seem consistent with organizational defensive routines embedded in the same culture. Some observers might claim that the process committee managers, standing to lose status by accepting “outside” proposals for change, are merely responding to the affordances in their organizational culture. Being rewarded for maintaining a process they view as standard and deterministic, and not as a learning process, they resist change to the standard, especially from “non-professional process people” outside their small authoritative community. Should the culture embrace a learning orientation, and reward members for knowledge sharing and practice improvement, such a resistance to change might be foreign. However, organizational learning environments are notoriously difficult to create and support within traditional organizations. Pilot initiatives are fraught with adoption challenges, and even successful results often fail to spread to greater organizational learning and participation.

Organizational culture spin-off

The single alternative innovation management process within the larger organization involved an entirely separate product development line, developing new products considered discontinuous from existing product lines. As described previously, this group created their own separate culture in effect, and abandoned all institutionalized processes from the larger organization. They developed specific new practices by choosing from the components of existing processes, and from best practices found within their own organization. They hired experts in a discipline if managers believed new skills were necessary. The expert was afforded the opportunity to develop appropriate practices within the group. Overall, their process management approach was conducted informally, without practices formally organized or even as much as “tied together.” Reportedly, knowledge was effectively shared throughout the group both officially and informally.

However, the inherent blocks to learning and sharing surfaced whenever practices were shared between the spin-off organization and the traditional product organization. Managers from the traditional organization refused to accept best practices or learning from the spin-off product group. An example illustrates the behaviors demonstrated when individuals attempted to advance their local processes by learning from the experiences from the spin-off group.

Team leaders in the traditional product organization had attempted to design an effective product acceptance process to become a broadly used component of Product Management. The new product organization had developed a robust management process for product acceptance, which was solicited for potential adoption by the service group from the traditional organization. The research participant had found their product acceptance process well-defined and immediately useful, and attempted to reuse and integrate it into their business process for product acceptance. However, this integration was rejected by her own management, due to the implicit policy of “not sharing” between the spin-off group and the traditional organization. Since the new product group did not use any of the mainstream official processes, the traditional organization had in effect disallowed the borrowing and reuse of any intellectual property or learning from this sister organization.

Discussion of Interpretive Analysis

Hermeneutic interpretations of product development process were performed for the cases of two product organizations, following emergent findings that pointed to significance of organizational cultural issues. The hermeneutic critique surfaced organizational patterns found across the multiple cases discussed within each organization, with nine categories found in Data Online and seven in Autoline Data. These patterns are not suggested to be a complete set of process dynamics in the product development organizational environment. These are the patterns elicited from the transcripted protocols, and no attempt was made to construct additional patterns by expanding the cases or joining other cases from the literature.

Table 5-4. Summary of categories from hermeneutic interpretation.

Moreover, interpretive analysis indicates that patterns from either case might explain behaviors in the other case. For example, development professionals in Data Online believed strongly in maintaining ownership of their work practices, and using processes that supported the necessary quality of their work. This principle might offer a recommendation to Autoline Data, where several projects were found without appropriate process guidance except high-level structures from the official product lifecycle. Autoline Data evidenced several useful approaches as well, which might address some of Data Online’s concerns. Autoline Data tended to fully appropriate their current available processes, even if not technically ideal. Ownership of process resulted in a consistent organizational language for product management, which could be powerfully adopted in Data Online’s more intellectual culture.

A paradox emerges from these cases. Both organizations evidenced cultural disregard for professional practices in favor of official processes designed and maintained by “process managers.” Yet, designers from these organizations also revealed distrust of these official processes and openly expressed the need to adopt more robust design practices, even if only locally applied at the project level.

The categories derived from the interpretations reveal some common dynamics between the two case organizations. These behavior patterns suggest that product organizations with traditional processes for innovation management may be associated with dysfunctional corporate cultures. If the purpose of a software/systems product organization may be simply stated as “to design, package, and distribute effective and usable systems as products to customers,” then the interactions described in both company’s cultures inhibit much of the competitive value available within the organizations. Certainly the business of software product development is highly competitive, requiring efficient work practices and intensive labor cycles to fulfill customer demands. However, these companies exhibited institutional disregard for known practices that could improve team coordination, organizational learning, knowledge sharing about customers and product design, effective and competitive product design, and employee retention.

Interpretive Analysis Summary

Certainly any one of these interpretive analyses may be argued to fit alternative explanations. These are not conclusive statements of fact, but astute participant observations drawn together by analysis and reflection. Together, they portray an organizational story much more powerful than any single critique might offer alone. The operating dynamics in these stories connect to embedded values in the organization that support and prefer the identified situations. For the most part, these values invest certain roles with preferential power, enabling those roles to access structural power for unknown benefit. However, the benefits and payoffs of power gained through embedding in process remain unclear. Most of these dynamics appear unproductive, using power for the sake of it, and restricting participation in the process.

Practice communities were largely unable to define their own codified process for their work, even while they are identified as the organization’s experts. Embedded values affecting this dynamic appear to function as a preference for management control (even if the process itself is insufficient). Processes defined by management teams leave little allowance for local knowledge. When global development processes (Product Management, CMM, and project management) were integrated into product innovation work practices, all developers and designers are affected The interpretations reveal that effective knowledge-based processes draw directly from the particulars of experience and professional knowledge, “from the ground up.” The interpretation must be made that management control of the particulars is valued higher than process excellence or professional satisfaction with work quality. The interpretative analysis recommended broad and active stakeholder participation in process design, using ad hoc committees instead of formal process groups, and evaluating processes for implied biases.

In fact, engineers and designers believed that workable design processes were “lightweight,” simple guidelines that allowed for professional experience and learning. Processes based on basic principles, light on detail, are easily used and maintained. Rather than attempting to codify all the pertinent knowledge in a local domain in one process, light processes support an appropriate set of activities and sequences. If a good process should “require framing useful questions,” one approach might develop a list of “expert questions” supporting flexible design and requirements. Local knowledge can be shared through other means (apprenticing, stories, Intranets) without burdening the community’s processes with details requiring maintenance.

By framing organizational dynamics in innovation management as embedded values problems, we gain insight into management rationale and mechanism. These organizations maintain processes that value the detailed control of work, whether productive or not. The values are embedded into the rights and responsibilities of the processes. These processes are mechanical – no single individual could change these processes if they wished (since they are ostensibly drawn by committee, their responsibility is diluted).

Taking this perspective, much larger organizational processes accomplish the same power function. Reorganizations were interpreted as command and control dynamics, serving only to reinstate and reinforce power relationships, as significant business purposes were not identified by participants. Given the upfront, overhead, and productivity costs of reorganization, we might expect to find a significant business rationale for the move. In the organizations analyzed, reorganizations merely served as a reminder that control still flowed from the top. With every reorganization, the “organizational battleground” became apparent, as “career opportunists” took advantage of the structural shifts. However, practice community members (engineering, design, development) shun this opportunism; practice groups serve as a source for professional satisfaction, and few engineers value negotiating the hierarchy of various management positions. Reorganizations also reminded people how organizational learning was discouraged. The regular cycle of reorganizing showed that “starting over” was important, not learning from the past and building those lessons into the organization and its processes.

In these analytic interpretations, multiple organizational factors were considered, such as culture, rewards, management metrics, policies, and resource competition. Embedded policies and management values were found throughout innovation processes, highlighted by conflicts between official process ownership and the needs of local practices to own their work. Without even articulating specific organizational values, their use in maintaining power relationships creates rifts in the organization, sustaining an environment where both values and process are rejected, and where practices are restricted from professional advancement.