Interpretive Analysis of Organizational Innovation Process

The case study analysis and survey responses made frequent references about organizational culture, suggesting further research into the organizational processes supporting product innovation. A second round of interviews gained further insight into organizational innovation and design processes and supported these initial case findings. These findings suggest that innovation and project management processes embed organizational values and propagate them through project activity. Thus, these implicit values and the associated behaviors become invisibly embedded and reinforced throughout the organization. This was the working hypothesis for the organizational innovation process interviews.

The intent of using hermeneutic interpretation was to understand the apparent dynamics of embedded values in organizational innovation processes, by interpreting factors relating to these processes and values. Focusing on the organization instead of project as the unit of analysis, the hermeneutic interpretation informed understanding of how organizational patterns embody values and meaning in official processes, routines, and practices.

A hermeneutic transcript analysis was performed for five organizational process interviews and the text from the ten project values interviews. This approach to hermeneutic content analysis reviewed each interview case for the unique voice and issues raised by the participant for their situation. Each project case was initially considered separately, and evaluated with respect to their context and experience of organizational processes. After this analysis, claims from across the sources were combined into groups with common themes. The analysis drew repeated themes and similar meanings from the voices, and organized them into a qualitative description for each of the two organization’s environments.

Throughout the interviews, participants often used the terms “process” and “practice” informally to describe organizational routines, requiring a clearer description of their usage. The term “process” refers to any institutionalized formal activity used to coordinate innovation management activity. This specifically refers to project management, product lifecycle, product definition, and software product development processes. The term “practice” refers to more informal activities carried out by workgroups or professional communities within an organization to accomplish more specific deliverables required of a project or product. In this research, the distinction between process and practice remains important in describing the behaviors and values responses to the use of process and the attempt to establish practice. The interpretive analyses that follow use these operational definitions in their descriptions.

Innovation Management Processes

To further investigate innovation management processes, the development processes and practices, their owners, and related activities were identified from the transcript data for the cases. Table 5-1 identifies the six common innovation management processes used in the two case organizations. Each process was evaluated for its adoption and eventual disposition, and each activity mapped to a “values locus,” identifying its organizational influence.

Table 5-1. Innovation management processes used by case organizations.

Specific processes from each case company are defined in Tables 4-6 and 4-7, from which the majority of cases were drawn. Seven elements define these processes.

1.  Product management process – The process name identifying the process or practice. An effective date span shows its lifespan from initiation to termination or replacement.

2.  Type – One of the six process types, elicited from the cases and described in Table 5-1.

3. Authority – The process’ level of official organizational support, where it derives its authority for use.

4. Diffusion – How the process spread in the organization, and its response to the process.

5. Level of control – The responsible process owner for its organizational span of use.

6. Locus of Values – Organization or group originating and representing the process.

7. Outcome - Disposition – The eventual disposition of this process in the organization.

Data Online Corporation

Context

Data Online Corporation was an early leader in online publishing, offering online access to news, business, and government information, and had achieved rapid growth in its first 20 years. As growth leveled and the organization matured, the company also found itself competing with new rivals on all publishing fronts. As competition affected profitability, the company forced two enterprise-wide reorganizations in the mid-1990’s, and was then purchased by a global publishing company, a trend in the publishing industry in the 1990’s. Following the purchase, two rounds of new management had extensively changed the composition of senior management.

Technology decisions in this organization generally involved a high risk, due to the centralized data available to the various products, wherein any changes to data affected all services. Therefore, engineering projects required a broader organizational involvement than similar projects in other companies, and extreme security was a fact of the culture. However, as the company grew, the culture also grew more formal and business driven. New standard methodologies and tools were deployed to achieve business control over development projects. Some of these methodologies ostensibly enabled better software project estimation and control. These methodologies also unwittingly imposed foreign and even inappropriate development approaches on professionals in development and design practice.

The interpretations are supported by personal experience as a consultant and participant-observer of over a period of five years. Many supporting facts for these interpretations draw from research and experience. The interpretations are drawn primarily from the interview text.

One of the compelling themes emerging for this organization was the difference between the standard processes for product management and the informal practices used by professional communities conducting the product design and development. The function of product and development process was undisputed – the need for an agreed and published approach to coordinating work activities was not at issue. The conflicts arose in two areas relating to organizational culture. First, staff managers responsible for instituting official process adopted official sanction for their process design roles, using process management as power over other professionals and their practices. And when design and development professionals constructed their own local work practices, the official management processes never sanctioned these practices, failing to sustain their value consistently across the organization.

The following sections describe the findings for DOC’s innovation management processes.

Organizational innovation processes

Table 5-2. Organizational processes in innovation management – Data Online.

 Data Online shows 10 innovation management processes in use from 1994 through 1999. Some of these processes were officially deployed in the organization. Others were evaluated 

for use in product development but were never adopted. The majority (6) were mandated by upper management or a process committee. Four of these were rejected in time, either through lack of adoption or by replacement. Organizational management owned the locus of values for all the standard/official processes. Practice community values defined the locus for practices owned by a professional group or community..

Three of the local practices failed to take hold, with only the Human Factors process continuing as complete. This process survived over four changes in management, and 40% staff turnover. New  Gate continues as an official framework, but in practice is used as guidance for setting product development milestones. The following interpretative claims were drawn from the hermeneutic analysis.

Ownership and accountability for process

Members of communities of practice (users and “owners”) responsible for using a codified practice for their work activities, should also design and constitute these product development practices. Processes are best defined, communicated, and deployed by their users, and not by “professional process people” who define processes but are not accountable for their use. Effective processes are built from local knowledge, “from the ground up.” They are “affordable,” ready-to-hand for their intended users to pick up and integrate into current work activity, and do not carry unneeded policy. For example, the users of the product design processes included human factors professionals, designers, and product managers to some extent. The design community researched best practices from similar companies and developed their own integrated process, designed specifically to fit within the company standard product innovation processes. These practices were often disregarded by the product managers, who preferred the use of either specific activities from the set of offerings, or no defined practices at all. Negotiations over process were typical, and were usually not settled in favor of the process owners.

Different professional communities value different types and levels of process. Software engineers require specific procedures used by all development team members (or the development work itself would be risked). However, different software development groups in the same company used quite different practices. Managers require business processes for managing the marketing, release, costing, and revenues for products. Project managers enforce between 7-10 processes used to manage project budget, requirements, schedule, and people. Human factors and design professionals require a defined process for conceiving, designing, and testing user interfaces. These preferred practices were often in come conflict with each other. However, design holds much less “authority” in innovation management than project management, due in part to project management’s claim on the schedule and tasks.

One of the risks inherent in process ownership is its inflexibility once instituted. In one example at this company, an outside design firm was contracted to work with a major project, and were selected in part for their well-founded and rigorous design process. Their process began breaking down after their application of their first phase on a large-scale Internet project. The project manager and the in-house design team had made design decisions in the meantime that obviated their proposals. One of the rationales for this breakdown was that as the product moves into a defined design, the risks become higher for selecting best feature alternatives and for maximizing the opportunity for innovation. Final design decisions for the user interface have the effect of lock-in, making it very difficult to alter fundamentals such as navigation, representation of features, or product architecture.

In this subject organization, product design and management processes were inflexible, since they weren’t easily modified to reflect current knowledge and best practices. The processes were also unpredictable, to some extent because the professional community, designers and developers, did not own them. Product managers stated their interest to use some degree of new innovation management process, but would also arbitrarily alter the process as they believed suited by the project needs. However, product managers themselves typically avoided defined procedures, in order to maximize their freedom to control, change, or act. Product managers were not themselves bound to practices that hampered flexibility, but this left other stakeholder unsure of the product management roles and responsibilities.

The organizational culture supported this state of affairs – projects were vulnerable to upper management intervention, at any time, without rationale or argument. Their behavior encouraged the management throughout the organization to perpetuate arbitrary interventions without regard to a design process.

Cultural integration of organizational processes

One of the consistent claims offered throughout interviews was the necessity of integrating any new product or innovation management process into the current organizational culture and values systems. Ignoring the organizational context would result in disuse of even the best designed processes, based on direct experience of participants.

Global organizational processes were found valuable when established as independent functions – independent of the reporting chain, whereupon no internal group or individuals would benefit to the disadvantage of others. Process independence was considered a necessary guard against arbitrary decisions, and reduced the likelihood of managers imposing personal agendas.

Product development organizations allow product managers substantial authority to make decisions on behalf of large-scale projects. At the same time, product managers typically recognize no “professional practice” endorsed as a discipline across the industry, as found with product designers and software engineers. Given this imbalance of authority and process guidance, organizations benefit by instituting product design and innovation management processes which all accountable staff and roles can adopt. The integration of such practices into a prevailing culture presents a politically challenging organizational design effort – the resulting practices require appropriate authority for widespread acceptance and a minimal learning and adoption rate to ensure use by multiple projects of varying skills.

Practice integration

One specific case illustrates the culture’s difficulty with integrating new practices. This company attempted to both redesign an existing Internet product (online research system) and to improve its design practices using a well-known Web design firm. The department responsible for product design and usability hired this external design firm to assist with design strategy, user research, graphical interface design, and product strategy. Using this consulting firm’s design process, the product design team learned and internalized applicable practices, and attempted to integrate these methods into their current process. The product design team also learned to formalize their own process based on this experience. Historically there was little structure in product definition (requirements process), and the external design firm’s approaches lent credibility to the recommended approaches. However, few of the practices learned were actually retained by the design team’s process; some methods were selected and modified, but an overall integrated approach was not defined. Instead, a collection of existing practices were brought together into a revised design process framework, but a complete, cohesive process was never instituted, even given their goal.

Affordance for customer access and knowledge

Knowledge of product domains also emerges as a cultural integration issue. The ability to ask questions (and being allowed to ask the questions), was seen as something afforded or disallowable by this organization’s culture. For product managers, designers and even engineers, customers and users represented the most important constituencies of domain inquiry. Access to customers for demonstration of product concepts, obtaining user feedback, and testing of prototypes was limited by the organization in three distinct ways. First, designers were supported in visiting users and customers only when sponsored by product managers for a specific funded project. Since customer inquiry processes were not organizationally recognized (formalized) as a standard design procedure, managers were inconsistent in their support for design inquiry. Second, even when user feedback was considered essential for product design, managers would often not support the necessary field visits, citing budget expenses or schedule reasons. And finally, even when designers were able to accomplish field visits to obtain customer responses to a product design, the findings were subject to arbitrary decisions by product managers overruling the findings. Therefore, designers openly discussed the difficulty faced gaining access to customers in the field as a power issues over control of product design.

Power in design decisions

Each of the three defenses identified afforded the manager maintaining unilateral decision-making over the product direction – user feedback was often considered unwelcome by product managers, since it represented perhaps the sole source of information with the power to change any of their predetermined positions. The product development and management processes defined requirements and established a projects’ scope internally, based on product market position and revenue considerations. Requirements were not defined using a process drawing from customer insights, or even features suggested from actual product use. Emerging user needs discovered on field visits were not always perceived as opportunities, then, but could be threats to the product manager’s stake in the product concept presented to management. Feedback on features and design was often considered threatening, and numerous cases were noted where product managers, intent on maintaining a defined direction, disallowed customer feedback that implicated against their design features.

Relationship to organizational affordances

Consider further the organizational implications of these interpretations. If customer inquiry was discouraged for designing a revenue generating product, what organizational affordance existed to question the culture that disallows effective inquiry? If the culture discouraged pursuit of “the right questions” due to hierarchy or political considerations, the organization could effectively stop learning about specific domains. Understanding of customer domain knowledge is necessary to design interactive information products that will be adopted. Hindering the designer’s learning in a domain could potentially lead to the designed product’s dismissal in the associated markets.

Organizational learning defenses in innovation

This organization revealed numerous situations where researchers and designers were unable to pursue the necessary questions for design; the organization seemed to block its own knowledge gathering and customer learning. Preference was given to departmental control of product-related organizational processes, and much of the research focused on internal technical capabilities, not on specified customer needs. Some of the projects faced with these conflicts faced eventual cancellation or demonstrated product design flaws that required successive releases to resolve. Meanwhile, opportunities for market position and customer acceptance were lost.

Formal standardized product development processes

Standardized processes for innovation management in software products are characterized by predetermined templates for coordinating activity. These templates define activities for all roles on a basis of organizational policy. Most formal, highly structured product and project processes were considered in retrospect, after their eventual disuse, as organizational disasters. One example showed how teams spent a substantial percentage of project time engaged in “poor requirements work,” losing the opportunity for design innovation by wasting the limited front-end time available.

Embedded policy and values

Official processes used as policy vehicles to legislate behavior were considered to embody dysfunctional values. “Process as policy” was considered insulting to designers and engineers; the inherent policy function embedded in processes betrayed a lack of trust of these professionals. A participant found the imposition of top-down project management and lifecycle methodologies from process staff or senior management wrongly focused. It revealed a conceit that business managers believed their control of intellectual work was more important than trusting those accountable for the work.

Embedded values impact on professional practice

Reliance on official processes allowed professional workers to avoid responsibility for their individual behaviors. Many procedures embedded in official development and management processes seem to practice communities as not merely overhead, but counter-productive. The tacit purpose of official processes seemed, or emerged as affording the advancement of privilege and power for individuals in the “business track.” This was perceived as biased against reasonable decision-making authority for design and development professionals.

For example, the Stage-Gate product lifecycle process (see Table 5-2) was deployed as a means of coordinating project activities in phases, affording management the opportunity at the “gates” to continue or to end project investment. Although the process was a typical project management oversight structure, it was considered (by designers and engineers) to not support either higher quality or better software development. There were no stated criteria defining appropriate business cases, product definition, or the quality of deliverables. Although Stage-Gate was not designed as a product management process, it in effect functioned as one, since no other product lifecycle procedures were available as organizational standards. One key process of Stage-Gate had visibly failed within a year of its deployment; the management oversight function of the Steering Committee had broken down due to continuing organizational differences among the Committee’s vice-presidents. When executives declared the Steering Committee function ineffective, management’s response was to replace the entire process. Instead of revising this function of Stage-Gate, the whole set of process routines was slightly modified and renamed as the “New Gate” process. This “whitewashing” of an official process weakened confidence in the organization’s ability to deploy effective management procedures in product management. User constituencies viewed the renamed and descoped process with cynicism. Identical routines were no longer followed consistently across the organization as they had been to some extent with the original Stage-Gate process.

Sources of embedded values

Some of the staff responsible for process management promoted an accounting approach to development processes and project management. This approach evolved in conjunction with using new project management processes deployed following a company-wide reorganization. In effect, the innovation management processes were aligned to accounting procedures using time and cost measures. These processes included the product lifecycle, project management, software development lifecycle processes and to some extent design and market research. This orientation was adopted by what some called the “process professionals,” the staff within the IT department responsible for defining and deploying standard lifecycle and project management processes. Since upper management valued “bean counting,” Quality Management and project management staff adopted accounting orientations to gain support and influence. One of the immediate impacts was to obviate an ongoing “grassroots” process redesign effort that was designed to support quality and teams. This community-based process effort was seen as challenging the new organizational structure. The new process committee dismissed their deliverables and approaches. The manager of the process group and the chief consultant favored the accounting approaches over “homegrown” routines that may have proven effective in local practice.

The “process accountants” were viewed as imposing a Taylorist efficiency worldview on intellectual property processes. One actual stated goal was “to make software development more like an automobile assembly line,” an assertion reflecting ignorance of the complexity and innovation in knowledge work. They had implemented the process tools of lifecycle management and the software package LBMS (a library of predefined software process templates) to control the structure of projects. However, this effort became seen as an intrusive means of imposing process control and accounting. The LBMS investment had required the professional process staff to spend six months developing and refining process templates before deploying the templates in projects in the organization. They further spent almost a year overall consulting with selected pilot projects, establishing project work breakdown structures and detailed task lists using LBMS. (I had direct experience with three of these projects, one of which I defined the original project template and made improvement recommendations to the LBMS process committee.) Informal practices recommended for product design were not easily accepted among managers. Even industry “best practices” in design, such as market research for customer evaluation, were usually not accepted when offered for use in large development teams. This organizational defensiveness reveals the priority of established channels of authority and policy. The organizational values embodied in these processes were identifiable as representing project management, cost accounting, and the implicit power of the reporting chain.

Scale and size of organizational process

The engineering and design communities have differing needs for process and procedures, but their philosophies for deploying them in the organization were similar. Processes used by design and engineering should be small in scale. One participant put this as “lightweight – say what you need to say and no more.” Detailed and step-by-step procedures are perceived as limiting or even insulting, as engineering and design professionals are typically well-educated in their disciplines and often have experience with multiple approaches and techniques. In any case, it was considered easier to learn, share, and communicate these leaner processes than the typical corporate handbook so commonly developed by “process professionals.”

Process guidelines should specify just the basic and necessary procedures. A codified process must also support enough flexibility to encourage users to experiment with the methods and to develop local innovations applicable to their projects. This subject organization held excessive management control of processes, leaving some highly developed local practices stranded with limited usage and no advocacy or dispersion. Autoline Data demonstrates several examples of locally-authored processes, but shows different problems, with their process committees neglecting to advocate these high-value local practices.

Informal and tacit product design practices

In this organization, product and project decisions were hierarchical and often controlled by top management. Due to this hierarchical locus of decision making, even industry standard product development and management techniques required division director acceptance, or they were not likely to be adopted by project teams. Some local practices, such as customer research and product interface design, were defined and used only within the design communities of practice. However, even these locally-accepted practices were subject to change due to project and product management control. They were typically used only to a limited extent on projects, when they were allowed. The practices were compartmentalized, applied inconsistently across projects, and the organization as a whole was therefore unable to learn from their prior use. Processes considered local, or that were loosely-defined, abdicated significant control of method, schedule, and deliverables to the project/product managers.

Avoidance of formal process

Experience with the product managers in control of the projects across the organization demonstrated that they used only minimally defined processes. When associate groups (design, research, development) requested deliverables of product managers, their response was often minimal, limiting the content of written contributions. Many, if not most product manager interventions were spoken, and conducted in meetings. Their avoidance of process appeared to be related to the management of authority. Avoiding process retained their freedom to make arbitrary decisions at any point in the project based on their role, which was perceived as a typical behavior. Since they were not as bound by internal agreement or by discipline to codified practices as researchers, designers, and developers, product managers simply did not adopt any formal process for the conduct of their management work or decisions.

Due to the consistent avoidance of effective or repeatable processes, designers requested the institution of two product management practices – that of the product vision and a consistent requirements process. These were considered necessary to support a consistent approach to product decision making throughout the organization. The design decisions and claims emerging from product team meetings were not traceable to explicit rationale, but were generated within the context of situated discussion. This informal decision-making approach often resulted in expressed differences between designers and product managers. Instituting an organizationally accepted product management approach or process was believed necessary to prevent the common problem of arbitrary design decisions and the pursuit of personal agendas.

Relationship of organizational power to design process

Breakdowns in project communication and product design were frequent, and many were attributed to the “total control” imposed by project managers. In one case, a project manager rejected most team contributions to the design of features unless they embraced her notions of the product user interface. Yet, this project manager never explicitly defined and specified her design notions, making it difficult to respond or innovate. Most decisions were made “on the fly” in conversation while critiquing product and feature alternatives, without reflection or even discussion. Designers were afforded little chance to discuss or build a case for features based on research or user tasks, which are the accepted rationales for design decisions in design disciplines. Decisions, once made, were in effect undiscussable within the team, as the project manager declared discussions closed.

Management of team activities

This specific description perhaps illustrates an extreme behavior, but this was typical across the range of projects in the organization, as described in the interview transcript. Unchecked decision-making power was fostered throughout the hierarchy, and learned by example by managers. Many product managers, project managers, and even technical leaders therefore maintained unilateral design control while avoiding documenting their decisions and specifications.

Other communication breakdowns resulted from the project manager’s control of the user interface design team, and control over an external design firm retained for design consulting. The same behaviors were exhibited - control of the design process, “gatekeeping” the ideation process (evaluating and discarding new ideas), not documenting design contributions or decision rationale, making secretive decisions, and maintaining poor communication within the team. These behaviors also resulted in organizational uncertainty about the distribution of power. Design and development team members expressed uncertainty of the product manager’s role, including the right to make decisions, contract research outside of the agreed group process, or to proceed with the design process. The entire project team was affected, hurting morale, productivity, and the capacity for invention. The two most senior designers from the group of six left the company during this manager’s six month tenure; within a year three more left.

Authority embedded in project management practice

One type of authority conflict within the design domain arises directly from the control of the software engineering development process. As the new (accounting-oriented) project management process was deployed, its focus on schedule and resource efficiency impacted the ability of engineers and designers to follow their professional practices. Tasks defined using standard work breakdown structures (WBS) and aggressive schedules impeded the use of even reasonable analyses and front-end research, considered necessary by designers to establish a product’s scope and brand identity. Decisions made by specific product managers often negated the recommended practices offered by the design/development professionals to ensure a quality deliverable based on professional practice. The espoused organizational values of quality and customer focus were overshadowed by the in-use values of political expedience and delivery speed.

Organizational impact of authority

When power interactions become a daily concern for employees, we can interpret that staff-oriented organizational processes, such as human resources, hiring criteria, and organizational development – have broken down. Identified as Model I organizations (Argyris, 1992), such organizations demonstrate reactive policies, and routines are highly controlled. (Model I describes organizations characterized by a focus on goal setting, rationality, a focus on winning at all costs, and the suppression of feelings.)

 For members of organizations that value professional identity and competence, such as engineering and human factors, an emphasis on hiring excellent people was considered to foster good practice. Engineers must collaborate and agree on practices for developing software products, requiring effective staff and therefore hiring practices. However, practices were defined or restricted by management authority. Having no credible knowledge of the professional practices they sanctioned, the organization’s ability to learn and develop competency was hindered. The control of practice and methodology was especially frustrating to new hires in engineering and design. Since new staff in these areas were hired based on criteria specified by practice leaders, the new hires often brought state-of-the-art techniques into the organization. After two or three attempts to use innovative practices in company projects, the new hires would limit further attempts to share their knowledge or best practices with project teams. By observation of 12-15 new hires, they were socialized into adopting the accepted tacit processes of the company in less than six months.

Management interventions affecting culture and process

Management values in-use confounded the impact of other factors, creating a mix of potential causes for organizational behaviors. How do organizational processes become structured to reinforce desired outcomes? Several factors in the organizational environment must be considered, such as culture, rewarded behavior, management metrics and policies, and competition for resources. Two factors were apparent; 1) Product management practices embodied both official policies and management values, considered antagonistic to design and to software development, and 2) constant management changes rendered the organizational environment unstable, so actors were uncertain of either their work’s value or of the organization itself to which they contributed.

Reorganizing power affordances

Just prior to the research, a major reorganization split the company into two divisions, with separate hierarchies, resources, and even data management infrastructures. Under this move, executives re-allocated software development and designers from the Information Technology organization and located them in one of the two new divisions. Engineers reported directly to business managers, initially portrayed as bringing developers closer to customers. Since no customer research processes were established to enable communication with customers, the intention of that pretense never occurred. However, the two business/product organizations now gained direct control over developer time and resource commitments.

The ostensible rationale for this reorganization was to intensify developer productivity by eliminating the negotiating power of the software engineering management, and by focusing software developers on business priorities established by product managers. Several related effects were immediately apparent – that developers and designers no longer had budgets for professional development or training, their opportunities for casual knowledge sharing and learning were diminished, and they were directly pressured for deliverables. Even the two business divisions themselves unknowingly suffered from the inability to share innovations between the two divisions, since developers and managers were too busy with the changes and demands of the new regime to communicate across the organizational border.

Professional management of innovation process

“Professional process people” as described in interviews could be considered organizational process managers. They are distinguished by the role of developing and influencing control of innovation management processes, but without financial responsibility or user ownership. Once formal organizations are established for process management, the organizational structures then become affordances for the career advancement of business people. Official processes (such as the Stage-Gate lifecycle) allow official opportunities for business staff to maintain personal and project visibility to upper management. These processes become aligned with the bias toward business process, wasting product and project team time and effort (described as “churn”) in business activities unrelated to the product effort. Some of these activities were identified as executive presentations, management checkpoint meetings, routine status and review meetings, and management review milestones.

Some organizational process managers were not aligned with the organizational initiatives, but became involved due to expertise and interest, such as with the Engineering Best Practices effort. Nearly all of these once-involved staff members had reportedly grown frustrated and left the company. One or two remained employed at the company in different capacities, and were available to this research. These process developers were distinguished by a genuine interest in designing workable processes serving multiple constituencies across the organization, and they held significant other job roles so did not depend on the process role for personal advancement. Significantly, they fostered participation throughout their efforts. In two cases, these process experts had created supporting organizations throughout the organization that remained on the org chart after they left. They had become “shells,” but management relied on them as if they were functional, and allocated resources to them. These shell organizations became staffed with remaining people, whose allegiances were aligned to the new organization, which had given them an official office for holding a form of organizational power.

Organizational re-learning

Reorganizations were used in effect as command and control mechanisms. Every time a new CEO was appointed (about every two years), new processes would be installed rather than learning from the current process initiatives. This cycle of process replacement was identified over the period of at least four CEOs. Organizational learning was actively discouraged, such as when professional staff asked an executive to consider lessons learned from previous and effective practices, the literal response was “stop living in the past.” In these cycles, highly qualified technical people were replaced, and it appeared that the replacement staff were rewarded for maintaining bureaucracy. Upper management’s focus on organizational structure explicitly maintained control of resources, initiatives, and other forms of power. Instead of understanding how work should be designed, the re-organizations in effect erase worker commitment to their own job or to common goals. To quote a participant from Data Online :

“So the big focus was on structure – being able to influence the org structure is what power and leadership means to them. So the organization is understood as, go change the structure so the structure works. Rather than, let’s help people get a better idea of what their work ought to be, let’s get some legitimate work commitment in the organization, let’s get people working better together, let’s get people more fully owning their own work. So basically if you want to be able to shift structure, or have people move into a different structure, or have people do a different job in a new structure without a sense of loss or grief, then you have to have people who are not committed to doing a particular thing. Because people who are committed to doing a particular job, if the job goes away, then they will also go away.”

Organizational affordances for power

An “organizational battleground” was perceived (by engineers) as waged between professionals with awareness of the broader organizational context (“having a clue”) and career opportunists advancing from taking advantage of the power shift. Each reorganization was seen to position opportunists where they could leverage management’s fears and vulnerabilities to their advantage. This gained them power to establish new product and project processes that addressed these perceived vulnerabilities, such as the financial control aspects of product management or the claim for the need for “world class development” as supported by a CMM Level III initiative.

Other conflicts between professional practice communities emerged along the lines of process management, with conflicts reported among project managers, designers, product managers, and engineers. One interpretation reported about the product development processes of CMM and project management was they institutionalized project managers’ contempt for software engineers. Specifically, the project management process focused on schedule and resource efficiency, a values system directly expressed to engineers without regard for their work, with its inherent complexity of intellectual property development. The CMM standards process also instituted a series of new official practices, most of which focused initially on project planning, project control, and requirements management.

One interview participant claimed that only very rare organizations (e.g., HP, AT&T, Intel) seem to support the development of managers with both technology and organizational competency. Instead, with every major reorganization, many top technical people left the company, and certain organizations were left with noticeably mediocre staff. When the organization becomes unbearable, even for a short time, good engineers can easily find better job elsewhere. A common claim was made that only the ones who can’t leave or won’t leave were staying behind.

Process intervention and managed enculturation

When global development processes (such as the CMM and project management processes) were integrated into the organizational work practices, some perceived their deployment as management intervention by force of process. When management processes are designed to leverage a set of rules that benefit organizational structures and context, they in effect reinforce existing power relationships and establish authority over professional practices that are not previously aligned with these relationships. Product designers and software engineers were not aligned as such, so their interests and requirements were not taken into account.

A special department staffed with “professional process people” was formed with the intention of institutionalizing a series of new design and development tools and methodologies. These approaches were deployed organizationally as interventions, replacing practices in current use by development groups. The new processes were mandated as if the practices were easily learned and interchangeable – however, many or most of the processes involved new terminologies, new methods, and foreign frameworks. The ensuing series of processes deployed and the systems and tools embodying the processes were described as “wave after wave of process people assaults,” a description denoting the profound impact of the change upon affected professionals.

The net effect of these organizational process interventions resulted in a deskilling (described as “dumbing-down”) of the development organization. Software engineers were required to follow the process templates proffered by non-engineering administrative professionals, and were not given the opportunity to modify the templates or their methods to better support their situated development practices. Furthermore, a new set of Microsoft software development tools was imposed as a new standard development environment; a senior engineer considered these tools oversimplified and inadequate for establishing the foundation software necessary for a family of highly complex software products. The transcripts identify the product-related values conflicts ascribed to Microsoft Visual Studio and other Microsoft products. These products were so clearly identified as examples of embedded product values, they bear sufficient weight to conduct following studies.

Cultural support for official process

In this company, an “official organizational” approach was adopted to institutionalize most new product development practices, specifically LBMS, project management, and the organization’s embrace of the Software Engineering Institute’s (SEI) Capability Maturity Model (CMM). Senior management decisions initiated the projects and resources to establish these processes; middle managers were not involved in selection decisions, except for the management process owner. These processes were deployed with the specific intention of addressing management’s perceived problems with project disciplines, time to market, product quality, and consistency of process across the organization.

The processes accommodated some organizational participation, but the participation was seen as titular. The managers of the CMM Level III process established a review committee consisting of 25 members from across the organizational groups expected to support the process. Documents prepared by the process managers were routed to the committee for review, and comments from members received specific responses, visible to all committee members. Comments offered by the committee were usually brief and suggestive, and were typically offered by the same 4-5 active members of the 25. In several cases, committee members offered very detailed responses requesting a change in process, providing substantial support for the position. In all cases these were denied by the process managers, for rationale such as the recommendations were “too advanced for this round,” even though the recommendations were common industry practices.

In one instance, two product designers met with the process managers and requested the opportunity to develop guidelines for an emerging practice, that of requirements use cases and scenarios. They were granted the request, and spent over 20 hours researching the issues, meeting with requirements process stakeholders, and proposing a simplified process that satisfied design and management goals. The proposal and the guidelines were rejected almost entirely by the process managers, and after further discussions, only a very limited version reached the overall committee in the process documentation. The result of this exchange was to extinguish participation; the process managers were then granted nearly every proposed practice without response from most committee members, since alternatives were seen as likely to be dismissed in similar fashion.

Integrated processes of other organizational cultures

Significant differences in culture were noted by participants between this organization and other firms in their experience. In one example, participants from the CAD, Inc. product company worked in a substantially different organizational context for management and product processes. At CAD, the development organization had demonstrated trust in the decisions and perception of the senior management. Senior managers had historically made decisions that led to positive courses of action and profitable outcomes. Since CAD’s management had traditionally moved up the hierarchy through engineering, the company’s core competency, they possessed a deep understanding of the domain and the technology. This was perceived as creating a much “tighter” culture, with less gap between the frames of reference of senior managers and development managers.

Whereas, in DOC’s culture, much of senior management had previously worked in traditional media publishing, and had diffused an aggressive culture from the publishing world into the company. This company had gradually shifted management over the years from technical managers that had developed the original online system to publishers managing the content and promotion. Longer-term technology and management staff perceived the strategies issued by senior managers as “hard to buy into, the explanations seemed tenuous.” Constant change and reorganizations diminished faith in stated strategy, since the strategy changed with every organizational shift on a yearly basis. This caused non-management staff to withhold commitment to some extent, as they merely need wait for the next reorganization to change people’s positions and roles.

Appropriate organizational process

A number of recommendations were implied in the transcripts for designing appropriate organizational processes for product management. One interpretation was raised that many of the organizational power issues and disruptive behaviors might be evaluated as counterproductive behaviors, enabling management to consider alternative approaches. The interpretations support soliciting broad and active stakeholder participation in process design, maintaining ad hoc committees and not establishing formal process organizations, and screening processes for implied bias against professional practice groups.

One consideration raised was the importance of “asking the right questions.” A participant stated that a good process should require asking good questions, leading to well-founded product requirements and project results. The organizational culture can afford the asking of good questions, or deny it. It can enable people from various roles to ask questions of customers, stakeholders, end users, and others; or the culture can restrict access, without even declaring such behavior off-limits. This affordance arises from the context of organizational history and informal conversations. As stated, “knowing the domain is cultural – asking the right questions (and being able to ask the questions) is part of the culture.”

Observations about innovation management process

Three characteristics of appropriate innovation process are distinguished from these claims.

1. An organizational process must be multidisciplinary, with a focus on customers, use of teamwork, and appropriate team roles to enable productive relationships and knowledge sharing. The engineering values of “competence” should be honored, as a starting point for evolving and recognizing other values that result from embracing competence.

2. The organization should recognize the need to fully engage people in ownership of a mission to which they can commit. When a team owns their mission, and the organization supports a workgroup/practice level control over one’s own work, team and individual performance issues diminish. The group and individual expectations for performing work become highly visible, as team members count on one another’s integrity, and not on authority to manage performance. With more autonomy given to teams, teams self-regulate the work and talent required for task performance.

3. Finally, it is important to develop practices that meet the needs of product management and design. For example, this organization’s Software Process CMM effort was oriented toward instituting standards for requirements and project deliverables as a first-year goal. However, as one engineer stated, “they could have a perfect process, but if the product definition process is bad, they could develop a perfect product that is way off the mark, that nobody wants.” The product definition process encompasses the design management and user feedback processes described throughout the discussions, which were shown vulnerable to arbitrary management decisions.