Many companies have experimented with various knowledge management (KM) practices since the early 1990s. There has also been substantial research interest that has considered the organizational, social, and technical issues associated with KM [13, 5]. However, there has been little previous research considering the challenges that the introduction of particular KM practices may generate for existing organizational practices.
Here, we focus on the KM practice of reusing components and subassemblies. Component reuse is the process through which product-specific components and concepts are shared across projects or products [9]. We examine the impact of the introduction of component reuse on the expertise development process of a company. We posit that there can be costs associated with some KM practices that have been underexplored in the literature. We conclude that companies must be alert to the unanticipated costs that may be incurred with the introduction of a KM practice and present complementary initiatives that can counterbalance the negative impact.
Given the limited research in this area, we adopt an in-depth case approach, focusing on Elisra Electronics Systems Ltd. A supplier of complex products [8], Israel-based Elisra has researched, developed, produced, and marketed cutting-edge electronic systems for over 30 years. Products were typically customized for each client, leading to high R&D costs as well as excessive exploration for each technological solution. Project teams often reinvented the wheel, taking little account of existing in-house solutions that could have been modified and reused. Eventually, given the competitive pressures in the industry, the company decided this approach to product development was no longer economically acceptable. Consequently, it sought to reduce the costs associated with the design process through the introduction of a KM practice that focused on reusing software and hardware components and subassemblies across projects.
We identified a tension that emerged between the practice of reusing components and the practice of developing expertise. More specifically, our analysis of this reuse practice showed that it led to fewer learning opportunities within the firm and it negatively changed the way engineers developed expertise and mastery. Expertise development is the learning process by which individuals and groups develop skills, know-how, identity, and meaning to facilitate their participation in organizational activities [11]. Component reuse is the process through which the exchange and sharing of project and technological knowledge and hardware and software designs between individuals and groups is facilitated [9]. In our case study, we identify two distinct phases, differentiated by the nature of interaction between expertise development practices and component reuse in the company. Phase 1 (19801995) refers to the years prior to the introduction of component reuse. Phase 2 refers to the period after the introduction of component reuse, where tensions surfaced between expertise development and component reuse practices.
Phase 1: Informal approach to learning and expertise development. In this phase, engineers were granted a high degree of autonomy in developing solutions that were customized to each client’s requirements. There was little control from management over the design process, enabling engineers to focus on developing solutions from scratch without searching for solutions that might be available in-house. Loose management control was possible mainly because the contractual arrangements with clients were based on a cost-plus structure. This ensured full coverage of all costs incurred in the development process. Moreover, management’s emphasis at that time was on designing quality solutions, further legitimizing continuous exploration to identify the best solution to a problem.
Highly developed and unique expertise contributed to solving difficult problems for the unique needs of clients so that skills and expertise were the most crucial elements supporting the design of the complex systems. Engineers developed their talents through an informal apprenticeship system that spanned years of practice under senior mentorship. Problem solving with experienced colleagues was at the center of the newcomers’ learning experience helping them to develop an understanding of the products, tools, organizational systems, and procedures that facilitated product development processes. Mentoring and apprenticeship contributed significantly to the development of expertise within the company, and learning practices evolved as part of the social environment rather than as a strategic plan. This approach to expertise development, however, involved high learning costs, manifested in the syndrome of reinventing the wheel.
Knowledge sharing, not preplanned, was achieved through social interactions and participation in problem solving. Thus, there were no formal (KM) processes established in Phase 1, with knowledge sharing occurring as a result of the unplanned processes involved as engineers mentored others while solving problems, and shared with others their expertise and understanding of organizational procedures and rules. The engineers were motivated by their desire to reinforce and gain accreditation for their mastery by demonstrating their knowledge through mentoring others. The engineers were also inspired to share knowledge in order to extend their participation in the innovation process.
In Phase 1, expertise development and KM processes coexisted in harmony and maintained coherence within the product development process. This was because the objectives of sharing knowledge (to be able to solve problems) were compatible with those of expertise development (developing mastery and knowledge of technologies). However, the approach to both KM and expertise development created a high cost to learning, and often led to technological development redundancy. Such inefficiencies eventually became a concern as competition in the industry intensified.
The Introduction of Component Reuse Strategy
The company introduced component reuse as a new strategy in 1995. Departing from the old practice of making heavy investments in unique R&D projects, management decided to enhance the reusability of existing in-house technologies. This meant that projects would have to utilize existing technologies as much as possible instead of designing and developing all technologies from scratch. To promote this approach, management nominated a chief scientist as facilitator for the transfer of technologies between different projects. Numerous configuration meetings were instituted involving the chief scientist, heads of professional fields, project managers, and engineers in order to create forums for the exchange of ideas about technologies and processes.
The company also introduced preliminary and critical design reviews, during which project teams were required to present their designs to other project teams. Additional initiatives that management put in place included setting up a new development group called the Application Specific Integrated Circuit (ASIC) team, which was responsible for designing and developing all ASIC applications in the R&D division. The rationale was that by centralizing ASIC development, costs would be reduced since not every project team would need to learn about ASIC technology. Thus, replacing exploration and reinvention with the exploitation of existing technology progressively became a main goal at the company.
Companies must be alert to the unanticipated costs that may be incurred with the introduction of a KM practice and present complementary initiatives that can counterbalance the negative impact.
Phase 2: Tensions emerged from the implementation of component reuse. The introduction of component reuse generated tensions in the design process. Here we summarize the concerns expressed by project managers and engineers relating to the introduction of component reuse:
- Engineers were frustrated because they were now expected to reuse technologies rather than develop new solutions. This was a source of tension between engineers and management as engineers felt this would limit their ability to develop unique solutions tailored according to client’s requirements. With the emphasis on reuse, engineers saw fewer opportunities to learn about new technologies, raising concerns among engineers about their personal development. In particular, some groups within the company were channeled toward work that proved very repetitious, where their existing skills were exploited and their access to learning activities was limited.
- Managers assumed that reuse could be achieved by simply transferring the design sheets of an existing component from one project to another. Engineers expressed concerns that this reuse process did not take into account the need to develop an understanding of the tacit nature of knowledge embedded in the “borrowed” design. This concern manifested in the frustrations that engineers experienced and in the problems that surfaced when teams tried to reuse components without having ways to access this tacit knowledge.
- Project managers and engineers were frustrated over the excessive number of meetings and design reviews that the component reuse practice had introduced. Tension mainly emerged around time and priority management of the source project. Project managers and engineers complained that the source project often dedicated limited time and granted low priority to component reuse, while the “borrowing” projects had to prioritize the reuse option and to dedicate time for searching in-house existing solutions in the early stages of the project. The main complaint was the coordination costs associated with the component reuse process might not be justifiable and undermined time available for skills development.
- Project managers and engineers were concerned that modifying the source design to incorporate components from other designs sometimes resulted in a lengthier (rather than the intended shorter) design process because it involved knock-on additional changes in subassemblies and other components, also known in the literature as redesign feedback loops [8]. These redesign feedback loops expanded the time dedicated to component reuse activities and further reduced the time left for development activities.
These issues illustrate how the skills and expertise development processes went through changes as a result of the component reuse initiative. The acceleration of the innovation process reduced mentoring and shortened learning time. Newcomers became involved in design after a relatively short time instead of being guided under a mentor in a drawn out problem-solving process. Thus, the new component reuse practice undermined the traditional learning process, which thrived on engineers’ continuous engagement in exploration activities.
Managers promoting the reuse strategy apparently believed the explicit knowledge embodied in the design document was the only important knowledge, thus ignoring the importance of tacit knowledge developed during the problem-solving processes of design. They viewed knowledge as a commodity that was essentially generic, accessible, codifiable, and context independent [10]. The managers assumed that engineers could learn from documents that outlined the results of previous problem-solving activities, without much need for firsthand experience with the problem-solving process. This assumption runs counter to what the situated theory of expertise development and learning [6] makes clear—that learning depends on situated practice, as occurred in Phase 1. The problems experienced by engineers were a reflection of ignoring the importance of situated practice and tacit knowledge. Essentially, the component reuse strategy undermined the established learning process and thus upset the development of expertise within the company.
Practical Implications for Component Reuse
The tension evident in this company, we conclude, is an illustration of the tension noted by March [7] between exploration and exploitation. We have illustrated this here in relation to the tension between component reuse (that was focused on exploitation) and expertise development (that facilitated exploration). Excessive exploitation of internal capabilities to the exclusion of exploration may lead to a trap where organizations fail to adapt because of a lack of creativity. On the other hand, organizations that engage in exploration to the exclusion of exploitation may find they suffer the costs of experimentation, which puts them at a competitive disadvantage. Both these excesses are therefore sub-optimal, and both were evident in this company.
In Phase 1, the problem was an overemphasis on exploration that meant product development was very expensive. Component reuse was introduced to redress this imbalance in Phase 2; however, this strategy led to an overemphasis on exploitation, which undermined the skills development of engineers and so the company’s capacity to innovate (explore). Our case analysis demonstrates how easy it is for the introduction of a new KM strategy intended to redress an imbalance between exploitation and exploration to have the unintended consequence of simply tipping the balance in the opposite direction.
The company acknowledged the challenges described in the table here, and took measures to offer engineers opportunities for learning without hampering efforts to increase the reuse of components. Indeed, engineers were offered learning opportunities not only in terms of technology development but also in the areas of technology management. Engineers excluded from the technology development process because of their involvement in component reuse were encouraged and found interest in specializing in the management of component reuse. These engineers developed new expertise imperative to the firm’s success. Furthermore, additional learning opportunities were offered to these engineers in those areas where they already possessed highly developed technological expertise, increasing depth of knowledge but without creating a lot of knowledge redundancy.
The company also introduced changes in the organizational structure of the engineering environment. Instead of the matrix structure, engineers were organized in two divisions: project and development. Project teams from the project division were responsible for managing the project from design to delivery while teams from the development division mainly carry out new developments or modify existing designs for reuse. This way, engineers from the project division have assumed responsibility for component reuse, guiding engineers from the development division to find existing solutions within the development division, and overseeing the redesign process.
Engineers from the project divisions are expected to specialize in component reuse processes by learning about the various solutions existing in house, the projects and product families that have implemented such solutions (“sources”), and the development technologies needed to make changes in these designs. These new learning opportunities encouraged engineers from the project division to develop mastery in the particular area of component reuse.
While these measures offered some learning opportunities and a career trajectory to engineers involved in component reuse, other challenges have not yet been properly addressed. In particular, the reuse of tacit knowledge and expertise embedded in a component and the proper management of time and priorities of both “source” and “receiving” projects have been neglected by this company to date.
To address the reuse of tacit knowledge challenge, we argue that such organizations should consider carrying out component reuse at the physical location where design and expertise development activities are conducted (for example, laboratories instead of meeting rooms), using similar tools and terminology (for example, oscilloscopes and simulation applications instead of design sheets). With these activities, the “receiving” team could gain insight into design considerations, and so get an improved understanding of the tacit knowledge embedded in a component, thereby also facilitating their skills development. Furthermore, moving the component reuse activity from the meeting room to laboratories may also improve the perception of time and priority associated with component reuse as this activity will be now carried out in the same physical space where design and development is conducted as opposed to meeting rooms, in which mainly discussions and decision-making processes are facilitated.
The time devoted to the reuse process must also be carefully managed. While only the engineers who design the “source” component can lead to the successful conclusion of a component reuse process by dedicating time and favorably prioritizing this activity, their involvement is actually needed only in the last stages of the reuse process. For the early stages, we recommend that the chief scientist, program managers, system architects, and project managers will assess whether a particular component can be reused by conducting feasibility studies, simulating the impact that redesign feedback loops in the “source” component may have on other modules in the system, and assessing the time required to complete a reuse process for a specific component. Following these recommendations will clarify the potential for reuse and will communicate management’s expectations in terms of time and priorities to both “source” and “receiving” project teams.
Last, but not least, by adopting some recent development methodologies (for example, component-based development methodologies [4]), suppliers of complex products may further improve the rate of component reuse and yet avoid magnifying the challenges reported here. Put simply, by designing components for reuse, such companies may even further integrate the process through which knowledge is created with the process through which this knowledge is shared and reused.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment