1 Introduction

Product developing companies must defend their position in the forefront of technology by investing large resources in technology development. These investments build capabilities that the companies will reuse in future products and processes. Actions of both managers and engineers affect how this growth in knowledge takes place, and they can nurture it by considering the potential of building knowledge during various types of decision-making (Barton 1995). Developing core competencies is about more than investing in research and development. It can also be fostered by regarding competencies as resources to be shared at a corporate level, establishing a roadmap of the competencies and technologies to build on for the future, entering strategic alliances, and explicitly identifying competencies to inform and encourage the entire organization to support its development (Prahalad and Hamel 2006).

Increased engineering reuse is a prominent way to cut both the cost and time of development by being able to “rapidly reconfigure products and services to meet specific customer requirements” (Antelme et al. 2000). Though the strategies connected to reuse of physical artefacts tend to generate higher profitability and prolonged lifecycles (Meyer et al. 2018), the same is not true with respect to the reuse of technological knowledge within engineering firms since this type of reuse has been identified to fail in about 50% of the time (Irnazarow and Heisig 2015). One reason for this mismatch may be that the reuse technologies is often taken for granted, since such competences typically lie at the core of a company’s competitive advantage. However, many companies do not take full advantage of opportunities to reuse their competencies and instead keep reinventing the wheel, with effects on both cost and time efficiency.

The contribution of this paper is to provide an overview of what practices that play a role in the capability to efficiently reuse technology, and thereby offer new insights to practitioners who want to improve reuse performance. The paper covers aspects on both a strategic level and an engineering level in order to provide a system perspective on how to unlock the opportunities of technology reuse. The presentation is structured with twelve key concepts identified in the literature and formulated as a framework, for easy access to practitioners. To further simplify the application, a self-assessment tool has been developed to help practitioners gauge their own abilities and shortcomings in relation to the framework. Further, a single illustrative case study is presented to exemplify the framework and how to apply it. The case concerns a technology development project run at an electronics manufacturing industry active in Sweden.

The outline of the remainder of the paper is as follows. The next section will clarify what perspective this paper has adopted on the ambiguous term ‘technology’. It is followed by a background to the design of the framework, with a base in knowledge management, and then the framework itself and a detailed presentation of its elements. Layers are added incrementally to a visualization of the framework to help readers follow the line of thought. After the practices have been presented, a discussion is provided on how the framework can be used by technology managers to identify practices that they need to improve in their organizations. There is a short discussion regarding managerial and engineering impacts, as well as a discussion of the need and potential problem to reuse technology. This paper uses a case study, partially presented in the conference article by Ivansen et al. (2018).

2 Technology viewed as a type of knowledge

Although most researchers and practitioners are comfortable using the term ‘technology’, its meaning is seldom clearly defined (Nieto 2004). It can refer to broad concepts, such as digital camera technology, which covers many different enabling technologies, or specific methods for manufacturing, such as laser welding. In this paper, the definition from (Burgelman and Siegel 2008) is used, which covers both broad and narrow meanings of the word: “Technology refers to the theoretical and practical knowledge, skills, and artefacts that can be used to develop products and services, as well as their production and delivery systems. Technology can be embodied in people, materials, cognitive and physical processes, plant, equipment and tools”.

Hence, technologies can be seen as elements of capability in a company’s larger collection of knowledge that allow them to develop and manufacture products (Schulz et al. 2000). Technological capabilities possess some specific properties that are not shared with other types of knowledge, including clear links to artefacts, improved possibilities to codify the knowledge, and a clear practical purpose, all of which make it easier to record and organize that type of knowledge into a system (Granstrand 1998). Hence, they lend themselves to opportunities for reuse across applications and product generations.

‘Technology development’ is in turn the dedicated effort to create new knowledge that prepares a particular technology for application in a product or system. Technology can be developed within the same project as its application, but the general recommendation in literature is to let technologies be developed in a separate process. This way, the execution-oriented application projects are protected from uncertainties inherent to technology development that would otherwise pose threats to both deadlines and budgets (Cooper 2006; Nieto 2004).

Engineers intuitively reuse previous designs and knowledge when performing new design tasks, either by complete carry-over of parts or through reuse at an abstract level, such as concepts or knowledge (Schulz et al. 2000; Smith and Duffy 2001). Inspired by reuse methodologies from software development (Duffy et al. 1995) argue that with a formal—instead of ad hoc—approach, the understanding of the reuse process would be improved, allowing engineers and companies to increasingly leverage their knowledge. Supporting increased reuse of technological assets requires both elements for how to develop for reuse and how to develop with reuse (Hunt et al. 2001). These two elements form the basis in frameworks proposed for technology and design reuse (Antelme et al. 2000; Duffy et al. 1995), together with recommendations to manage the storage of information, classification of technologies, as well as the decisions to implement and develop certain technological assets (Antelme et al. 2000). In their framework, they list four types of reusable technology assets: physical artefacts, processes, core competences, and capabilities. They argue that all of these reusable assets are included in a broad definition of “technology”, and continue to define engineering reuse as technology reuse.

3 Methodology

This paper is a theoretical review paper, focusing on the existing literature regarding technology reuse. To structure the identified work, four principles were listed and related research was ordered into these areas. The presentation is structured regarding twelve key concepts identified in the literature, formulated as a framework, and then exemplified with two self-assessments and one detailed case retrospective from the authors own experiences of technology development companies in the aerospace and electronics manufacturing industries active in Sweden.

3.1 Verification of the framework

A self-evaluation template with questions for each practice of the framework is presented in the appendix as support for making self-assessments of technology reuse capability. The assessment uses subjective scoring in two dimensions: (1) how relevant the practice seems to the unit being evaluated (e.g. company, product area, or business unit), and (2) what the current performance is on using the practice within the unit. Subjective measurements are proposed since it is difficult to adequately measure how an organization is performing in these areas, which also means that the scores represent how the assessors perceive the relevance and performance of the practices. The primary value from using the assessment is likely to come from the conversation and insights generated in the process of filling out and discussing the assessment.

Further, an illustrative case is introduced in the paper, to highlight the principles using a retrospective study of a technology development case at a Swedish manufacturer of electronics manufacturing machines. Although only one case, it shows the applicability of some of the identified principles and how the framework could be used to identify and avoid problems relating to technology development and reuse in engineering.

4 Building a framework for technology reuse

Traditional frameworks for technology reuse and engineering reuse typically aim to set up dedicated programs and processes for identifying, assessing and implementing reusable assets (Antelme et al. 2000; Davis 1994; Duffy et al. 1995). A more recent approach connected particularly to engineering is the continuous development and utilisation of Knowledge Based Engineering (KBE) (Reddy et al. 2015). There are also prominent research connected to e.g. knowledge reuse systems in detailed processes, such as a manufacturing system (Efthymiou et al. 2015). This paper takes a different approach by regarding reuse as a process that occurs naturally during development and that can be improved by adopting the right practices at different levels of the organization. Most companies can likely benefit from increasing their capability to reuse technological knowledge, but a dedicated reuse program with prescribed processes to optimize its benefits can overshoot the goal for many organizations in light of all other priorities they face. The lightweight framework based on a literature review as suggested in this paper features a combination of general practices in technology management that influence technology reuse and practices that specifically support reuse. The important aspect of this literature review has not only been to identify available literature on the subject, but the contribution also lies in assessing the potential of the principles from a bottom-up perspective, i.e. the engineering and practical perspective facing technology developers in engineering companies. There are synergetic effects between the practices in the framework, but they can also be implemented as separated principles to transform an organization organically into one that is proficient in reusing its technologies.

With the perspective that technology is a type of knowledge, knowledge management theory is a good starting point for creating a basis for theory on technology reuse. Knowledge management literature presents a host of challenges pertinent to the transfer of knowledge applicable to the case of technology reuse by different teams (Thomas and Obal 2018). The key characteristic of technology that distinguishes it from more general knowledge types is that it is applied to the design and manufacture of products, focusing on the technical “know-how” of the organization (Phaal et al. 2004b). The success of knowledge management initiatives and activities is highly dependent on the infrastructure, i.e. the processes, tools, structure etc., to which they are implemented, which is also true for the management of technological knowledge (Heisig 2009; Phaal et al. 2004a). After comparing 160 knowledge management frameworks, Heisig (2009) identified four categories of key factors for creating a successful infrastructure: human-oriented factors (culture, people and leadership), organizational aspects (structures and processes), information technology (applications), and management processes (strategy, goals, measurement and control). The next section presents a framework with practices that support each of these categories, respectively, and are particularly important to the management of technological knowledge.

The method for arriving at the practices included in the framework was through a continuous growth of understanding by reviewing literature related to technology reuse and their references, mainly found in research on technology development, technology transfer, design reuse, and knowledge management during the course of a five year research project. Different practices mentioned in the reviewed literature were collected in a list and then synthesized into twelve practices, which are presented and explained in this paper with references given to the research from where they were identified.

5 Framework for the capability to reuse technology

This section describes a framework featuring twelve practices that form basis for the capability to reuse technology. The framework borrows its categorization scheme from success factors for setting up an infrastructure for knowledge management from Heisig (2009), ranging from strategic to operative level, in order to support organizations to: (1) set a strategy that creates a pull for technology reuse, (2) develop processes that support technology integration, (3) create a mind-set and work methods that result in reusable assets, and (4) adapt systems that support the management of the knowledge that constitutes the reusable technology assets.

The full framework is visualized in Fig. 1 as a technology and product development process with all twelve practices included.

Fig. 1
figure 1

Framework for the capability to reuse technology. The framework is based on the concept of product value stream and knowledge value stream as presented in the lean literature by Kennedy (2008). The illustration shows that technology development as a separate activity that feeds the knowledge value stream with new reusable knowledge assets which can then be reused in the product value stream (product development and product roadmaps). The technology platform is used to highlight mature technologies while the technology roadmap includes technologies that are either planned to be introduced or are currently being developed in technology development projects. This image is further detailed in the paper by Levandowski et al. (2013)

Full size image

As the four categories of practices are introduced below, they build up to the overall framework by cumulatively adding the practices related to the categories respectively. The starting point is visualized in Fig. 2, which shows a development process featuring development projects “a” and “b”, including technology and product development, as well as a pool of technological capabilities that are possessed by the organization. The capabilities are depicted as “floating around” to illustrate that they are not managed systematically, as in a technology platform or roadmap. Larger circles indicate a more mature technology.

Fig. 2
figure 2

Ad hoc development process without any of the practices of the framework (Fig. 1), including a pool of technological capabilities held by the firm and two separate development projects (a and b) resulting in two different products. As part of the product development, project a also develops two technologies within its scope (or adapts them to the new application from an earlier implementation) and project b develops one technology. No structured reuse of technology is possible since the capabilities are not managed systematically

Full size image

5.1 Strategy: platform thinking

Platform thinking is the process of identifying and exploiting similarities between products (Sawhney 1998), and a commonly used approach to leverage developed capabilities. The following three practices have been identified in this category and are visualized in Fig. 3:

Fig. 3
figure 3

The development process from Fig. 2 with the addition of three related strategy practices supporting technology reuse. The technology platform and roadmap as depicted in Fig. 1 is now added to facilitate a structured reuse of known technological capabilities. This approach also opens the possibility to better select new technology development project as what you know and not know is now better structured. The introduction of a product platform further increases the potential of reuse of physical artefacts, which is beneficial, but out of scope of this presentation

Full size image
  1. 1.

    Product Platform Strategy: Create product families with shared modules and components

  2. 2.

    Technology Platform Strategy: Strategically invest and monitor competences that are useful to multiple product areas and business units

  3. 3.

    Technology Roadmap Techniques: Visualize and plan the evolution of the technology base

5.1.1 Product platform strategy

One of the most prominent approaches to enable both development for reuse and development with reuse is product platforms. The classic product platform approach is to develop the architecture or components upfront in preparation for the development of a family of derivative product variants later on. Platform strategies have received a lot of attention because of their potential to leverage internal assets to meet a wider range of market needs. Other advantages of platform strategies reported in literature include: increased development efficiency (Robertson and Ulrich 1998; Simpson et al. 2006), improved ability to update products (Simpson et al. 2006), the promotion of learning about complex products (Rothwell and Gardiner 1990) and improved design quality (Sawhney 1998).

Leverage of the product platform often comes from the developing product families. Lehnerd and Meyer (2011) define a product family as a set of products that share common technologies and address similar market applications. Other authors have looked at modular platforms and scalable platforms, which relate more to the product or the product structure. Hence, there is a range of different types of product platforms. Some limit the scope of the platform approach to physical components, while others also include intangible assets such as underlying technology and knowledge (Simpson et al. 2006).

5.1.2 Technology platform strategy

The core technologies in product platforms can act as their foundations for uniqueness and as sources for product success (McGrath 2000). When Lehnerd and Meyer (2011) model a generic platform strategy, they incorporate technologies in a foundational layer together with three other generic capabilities upon which product platforms are built: Customer Insights, Manufacturing Processes, and Organizational Capabilities. Some authors define a technology platform as a distinct approach, e.g. (McGrath 2000): “a set of initiatives organized around a macro-level functionality that helps to manage and optimize technology investments across multiple product platforms”. According to these definitions, technology platforms represent the core competencies for technology-based companies, which do not lend themselves to the building block modules and interface structure of product platforms. Unlike product platforms, they also capture both physical and non-physical elements, where the company 3M is a clear example with a technology platform based on elements, such as adhesives, abrasives, and vapour processing (Shapiro 2006). Some authors argue for the use of narrow technology portfolios, while others advocate diversity as a way to increase performance (Lin and Chen 2005).

There are methods to support portfolio management that can also be useful to visualize the current state of technological competences possessed by an organization. Literature on technology portfolio management is generally focused on how to plan for the development and phase-out of core technologies e.g. (Van Wyk 2010). In order to assess projects in a research and development portfolio, there are two types of metrics: management science techniques and graphic decision support (Linton et al. 2002). Management science techniques use numerical data on e.g. costs and anticipated future value to rank projects or assets, while graphic decision support helps visualize various quantitative or qualitative characteristics in a format that is more comprehensible for decision makers. An example of the latter is proposed by (Schulz et al. 2000) who use a bubble diagram to represent the contribution from technological capabilities based on four metrics: (1) contribution to customer satisfaction, (2) technological strength, (3) technological maturity, and (4) superiority compared to other technologies in terms of e.g. cost or performance.

5.1.3 Technology roadmap techniques

Knowledge about technologies can be seen as an inventory of information and experience that management can work to optimize (Levinthal and March 1993). The challenges in optimizing this inventory have to do with the uncertainties of what will be needed in the future. When you know what you need, it is too late to acquire the knowledge, and in advance you cannot know precisely what you will need (Levinthal and March 1993). When deciding about the contents of a knowledge inventory, the levels of variety and depth of knowledge are important to consider since they support reuse in different ways. Knowledge that is simple and tied to a specific application can easily be interpreted for existing products, whereas knowledge with more variety and depth is more difficult to interpret, but lends itself to opportunities for adaptation to changes.

According to Jolly and Nasiriyar (2007), technology platforms serve the purpose of “harmonizing and coordinating a stream of technologies within different businesses” (p. 14). Technology roadmapping is one technique to achieve such harmonization (McGrath 2000; Phaal et al. 2004c) with the specific purpose to “develop, represent and communicate strategic plans, in terms of the coevolution and development of technology, products and markets” (Phaal et al. 2004c). The harmonization is created by identifying products likely to suit a future market and then deriving their functionality and technologies needed to fulfil this market. The technologies and products are plotted on a timeline to provide an overview of planned development projects. Such a timeline can support both strategic management and detailed planning by including a planning phase for the following 2–3 years and a vision phase covering additional years into the future (Groenveld 2007). The creation of system-level technology roadmaps needs to take place at a high level in the organization to align the views of different functional areas, in addition to aligning long-term and short-term planning (Petrick and Provance 2005).

5.2 Process: supporting technology integration

Capability for reusing technologies can also be built into the design of development processes, e.g. by assigning designated stages for reuse exploration and securing that reused technologies are in fact compatible with their new environments. There are three practices that have been identified for the design of development processes and they are visualized in Fig. 4:

Fig. 4
figure 4

The development process from Fig. 3 with the addition of three process-related practices supporting technology reuse. The addition of the technology development process and the structured measurement of technology reediness (illustrated by the thermometers) enable decoupling of the product and technology development capabilities of the firm, as well as more accurate risk assessment of integrating an immature technology in product development

Full size image
  1. 1.

    Separate technology development: Separate the technology value stream from the product value stream to allow broader targets for exploration of technology potential

  2. 2.

    Measure technology readiness: Measure technology readiness levels to keep track of technology feasibility in various applications

  3. 3.

    Assess reusability: Use technology element reuse assessment for evaluating potential reuse of technologies in new product development projects

5.2.1 Separate technology development

Technology development and product development are often managed separately to equip them with suitable methods and process models (Schulz et al. 2000). One reason to do so is to steer technology development toward flexible technologies that may be used in multiple products (Clausing 1994). Whereas some literature presents the alignment of technology development and product development as a temporal division of the same process (Cooper 2006; Eldred and McGrath 1997b), albeit with some overlap, Schulz et al. (2000) prefer to model them as two parallel streams, from which product development is collecting, or “fishing out”, appropriate technologies from the technology value stream.

5.2.2 Measure technology readiness

By measuring the maturity of a technology, the remaining risks and costs of further development can be estimated to facilitate the decision of when the technology may be ready to be transferred to product development (Nolte 2008). The most widely adopted metric for assessing technology maturity is Technology Readiness Levels (TRLs), which were originally developed by NASA (Mankins 1995). The scale has nine levels (1-9), where the highest levels indicate the existence of a complete prototype that has been verified in environments that closely resemble its intended application. At the other end of the scale, technologies with the lowest TRLs are still undergoing stages of basic research, whereas the middle levels often correspond to proof-of-concept studies in lab environments. Technology transfer studies focus on the multidimensional aspects of the transfer and the difficulty in both measuring and perceiving the immediate or long term effect of knowledge transfer (Bozeman et al. 2015).

Technologies do not work in isolation, and their implementations and performance are contingent on the surrounding product systems. The maturity of a technology can thus only be judged in the context of a specific application, as follows from the definitions of “Technology Readiness Levels” (TRL) that are commonly used in the defence and aerospace industries. For instance, TRL 6 is defined as “System/subsystem model or prototype demonstration in a relevant environment (ground or space)“, where “relevant” can mean in terms of external requirements and interdependency with other technologies and systems. By introducing assessments for technology maturity, an organization becomes more aware of the complications of bringing technologies into applications and learns how the environments in which they have been tested dictate the conditions in which they can be used.

5.2.3 Assess reusability

When reusing a technology in a new application, new uncertainties will surface about the technology’s performance. These uncertainties are easily underestimated because of the fallacy of perceiving a technology as a “proven capability” that can be used off-the-shelf, but in the definitions of the higher technology readiness levels there is always an application towards which it has to be tested. Further, reusing a technology for a new product typically means that a new team will work on its integration in the product system, and they would need a deep understanding of the technology to overcome challenges of adaptation that will likely occur. Technology reuse can thus be regarded as an event that occurs in two different contexts: (1) a technology recontextualization effort in the product context and (2) a transfer of technological knowledge from a source unit to a recipient unit in the organizational context (Molas-Gallart 1997). Corin-Stig et al. (2015) have proposed an assessment methodology for identifying potential difficulties in these two contexts to help companies ensure that a reuse effort is not underestimated and can be correctly planned and executed with necessary knowledge transfer mechanisms.

5.3 Culture: creating reusable assets

Assets are created and reused within development projects, so the values and culture that drive these projects are key to a technology reuse capability. The execution of these projects can be supported through the following four practices that are visualized in Fig. 5:

Fig. 5
figure 5

The development process from Fig. 4 with the addition of four culture-related practices supporting technology reuse, for example, to set goals for explorations indicates a more structured and goal-oriented technology development process. Design for and by reuse indicates that technologies are researched based on multiple application areas, rather than one single application area

Full size image
  1. 1.

    Set Goals for Exploration: Set objectives for technology development projects that are broader than single applications to prepare technologies for a range of requirements and applications upfront, e.g. using real options thinking (Steffens and Douglas 2007).

  2. 2.

    Design by reuse: Use design by reuse techniques to identify useful previous technologies and experiences.

  3. 3.

    Design for reuse: Value the use of design principles that support active design flexibility, where products and technologies can operate in different conditions or be easily adapted to new environments.

  4. 4.

    Domain expert groups: Implement a functional or matrix organization, where domain experts sit together. Alternatively, organize communities of practice and cross-functional groups to share experiences.

5.3.1 Set goals for exploration

Depending on how broadly the capability and limitations of a technology have been explored during its development, it can be ready for application in a wide or narrow range of applications. This range of possible applications is also influenced by the type of technology being developed–some are more generic than others–and the way the results are stored and disseminated.

Technology development is a knowledge-creating activity, and its results are inherently intended for application in products and manufacturing systems. Given the time pressure on most development, there is often an application project that needs to be synchronized with the technology development, while expecting its results in time (Eldred and McGrath 1997a; Nobelius 2004). In order to make capabilities more generic with potential for future reuse, it may be better to experiment in a realm longer than necessary for the immediate application. When discussing the development of core capabilities, Prahalad and Hamel (2006) suggest that individual business units tend to underinvest unless provided with a broader perspective from corporate management on the benefits to the company at large. With equipment set-up and knowledge being at the top of the minds of the development team, the marginal cost of testing the limits of the capabilities are very low compared to restarting the process at a later stage to extend the technology to new applications. Schulz et al. (2000) propose a technology development process that features a phase called Robustness Development and Analysis dedicated to making the technology more flexible and mature. It explores reusability aspects that make the technology more robust to the uncertainties in requirements from subsequent product application projects.

To enable companies to benefit from designing for reuse, they need methods to assess the reuse potential of a design (Ross et al. 2008). There have been several measures proposed to quantify the amount of flexibility in a design and a few which aim to assess its value (Ryan et al. 2011). Wadhwa and Rao (2000) conclude from a review of measures on flexibility that they there are many parameters to consider and they extract a number of general concepts that make a system more flexible: “if it can handle a wider range of changes, if it has a greater number of options to counter the effect of change/uncertainty, if it can attain a new state (within the range), in a shorter time, at a lesser cost, with lesser effort, with lesser disturbance/imbalance, etc., if the effect of an unpredictable change (such as machine breakdown) on the performance of the system (such as drop in production rate) is less, if it can change its flexibility based on specific needs, in an easier manner (flexibility of flexibility!)” (Wadhwa and Rao 2000).

A commonly mentioned method for assessing the value of flexibility is real options (Saleh et al. 2009). The concept compares the price of preparing for a situation, e.g. a change in market conditions, with the value of having made that preparation. Since the predicted situation may not occur, the upfront value is not the same as the value when the prediction turns out to be right. The preparation is here referred to as an option to act efficiently in a specific future scenario. Its value is calculated by multiplying the probability that the situation occurs with the value of having the option in that situation, subtracting the cost of realizing the response. If this value is higher than the additional investment for having the option, the investment has a positive expected return. In reality, the equation is much more complex and Eldred and McGrath (1997a) discusses several other factors that affect this decision. One of these factors is that the value of the option must be considered in relation to other options, and developing two technologies to meet the same situation reduces their values, since there may not be an additional value of having both. Another factor is that development activities often create positive spill over for other products and technologies as the organization increases its capabilities.

5.3.2 Design by reuse

When solving design problems, there needs to be a culture of searching for previous knowledge resources before designing something new for reuse to take place. As discussed in subsequent sections of the paper, organized repositories where information is formatted for reuse greatly support this practice by making sure that preconditions are good for easy identification, acquisition, and application of existing knowledge.

Reuse of assets can take place on different levels of abstraction (Duffy et al. 1995), from the abstract descriptions in design patterns and design guidelines to reuse of complete components. Technologies vary in the degree to which they can be directly applied in new contexts. Some are embodied in component modules, such as the GPS chip in a smartphone, while others need to be tailored to the application, such as for welding technologies for aerospace engine components.

Understanding what is needed to adapt an old solution to a new problem may require specific expertise, which then needs to be made available to development projects (Smith and Duffy 2001). In a functional organization or where there are active communities of practice, this expertise is likely to be more available, and knowledge records that explain the rationale and history of previous designs help this assessment and recontextualization process (Busby 1999; Smith and Duffy 2001).

5.3.3 Design for reuse

Saleh et al. (2009) found in their review of flexible engineering systems that research results are divergent regarding both how to achieve flexibility in design and how to compare its value to other performance attributes. Besides platform-based design and modularity, they mention adding design parameters and design margins as ways to achieve flexibility. However, it is not feasible to systematically overdesign products and technologies without a good reason based on cost and benefit.

As mentioned previously, Schulz et al. (2000) dedicate a separate phase late in their proposed technology development process to increase the robustness of technologies through testing and adjusting them to variations in their operating conditions. Hence, by robustness they refer to the ability of technologies to perform under a range of conditions, which also makes them reusable for more products.

Fricke and Schulz (2005) discuss how to achieve robustness and flexibility in design through nine principles supporting their “Design for Changeability” framework. The first principle is simplicity and it is attained by reducing complexity, for example using existing resources to accomplish functions or by reducing the number of interfaces and secondary functions of a system. The second principle is independence, which states that the coupling between design elements or parameters should be low, and functions should be satisfied by independent parameters. Modularity is the third principle and it is achieved through developing “self-sufficient, distinct, and not intimately integrated units”, e.g. with a platform approach. The fourth principle is integrability and states that interfaces should be kept generic and compatible as opposed to proprietary interfaces. The remaining principles are autonomy, scalability, non-hierarchical integration, decentralization and redundancy, where the latter is a form of overdesign. Fricke and Schulz (2005) stress that these principles can both enhance each other and be in conflict, so a contingent approach is needed to achieve the right level of flexibility.

5.3.4 Domain expert groups

In large organizations and in project-based structures, it is likely that there are multiple groups working with similar tasks. The knowledge then needs to be transferred between the groups to enable effective reuse of the technologies. Especially for tacit knowledge transfer, a personalization strategy realized with solutions, such as yellow pages, face-to-face interaction, and mentorship programs, is important (Catic 2011; Yeung and Holden 2000).

Functional organizations have a strong advantage for making sure that knowledge is reapplied in subsequent products, since specialized groups are repeatedly working with the same subset of tasks (Wheelwright and Clark 1992). These groups also need to be aware of their environment and the overall functioning of the products to manage the part-whole relationship and to be able to renew their capabilities (Van de Ven 1986).

Another approach to spread knowledge and share experiences among people within the same functional domain is ‘communities of practice’. These are groups of people that stay in touch through e.g. regular meetings or email in order to support each other solve problems or report on new developments. They are unique in that they are informal and that participation is voluntary, but they can still benefit greatly from support by initiatives from management (Wenger and Snyder 2000).

5.4 Information technology: managing knowledge

Knowledge management activities in product development can be divided into two types; knowledge creation and knowledge application (Catic 2011). Most attention has historically been given to the creation of knowledge, but the effectiveness of reusing knowledge solve recurring technical problems is highly relevant to achieve organizational effectiveness (Markus 2001). Knowledge is often the main outcome of technology development and strategies for knowledge transfer and reuse are crucial for increasing the usefulness of the development results. The two practices are visualized in Fig. 6 and can be expressed as:

Fig. 6
figure 6

The development process from Fig. 5 with the addition of two IT- related practices supporting technology reuse

Full size image
  1. 1.

    Knowledge Repositories: Use knowledge repositories that allow employees to find documents for reuse of technology, e.g. test reports and design guidelines.

  2. 2.

    Format for Reuse: Actively use and update design guidelines and handbooks on how to utilize existing technologies when new products are developed, including information about what is yet to be tested in order extend the use to new conditions.

5.4.1 Knowledge repositories

Knowledge can be categorized as tacit or explicit depending on the extent to which it can be expressed, codified, and stored (Nonaka 2002). There is disagreement about the relative importance of these two types (Markus 2001) and different strategies support their transfer and reuse (Catic 2011; Yeung and Holden 2000). Explicit knowledge transfer is primarily supported by a codification strategy, often operationalized with information technology solutions. Much research has been performed about how to capture explicit knowledge in digital libraries. Willingness to contribute and the rate at which users access and use the digital repositories are the two main concerns for making these libraries effective (Watson and Hewett 2006).

Markus (2001) identified four types of situations where knowledge reuse takes place, and suggests that they dictate the particular needs of the knowledge transfer. The first reuse situation is when knowledge is recorded by someone working within the same context, such as a co-worker in the same project. The second situation is when someone working on a similar problem in a different context can benefit from reusing knowledge gained by someone else, e.g. during a previous project at the company. The third situation is when someone seeks expert advice about something that they are not knowledgeable in, and rarely in need of. Lastly, the fourth situation is when someone is trying to create new knowledge or answer new questions by reviewing a collection of knowledge recorded for other purposes. These situations face different challenges regarding how to know what to look for, how to find knowledge, how to assess whether the knowledge is relevant, and the ability of the knowledge seeker to acquire and apply that knowledge. For instance, a novice who seeks expert advice would need decontextualized knowledge with indications on how to recontextualize it, while those reusing the work of their own group want the context to be maintained in the presentation of information.

When creating repositories of knowledge, there are a number of critical challenges to make them useful; the willingness of employees to contribute, their accessibility and ease of use (Watson and Hewett 2006). In order to support reuse, it is vital that these repositories are organized, and not just bins of information (Duffy et al. 1995). Employees who find such systems useful are more likely to make contributions to them and make sure they contain updated and trustworthy information (Watson and Hewett 2006). Knowledge repositories based on Web 2.0 solutions, such as blogs and wikis, have been proposed as means of facilitating knowledge sharing and even providing a channel for transferring tacit knowledge (Standing and Kiniti 2011). However, these repositories still require a culture of sharing and collaboration, as well as ease of use, in order to be effective. Some people voluntarily take on the role of “information shapers” and reorganize and edit content to improve readability and searchability for others (Yates et al. 2010). However, there is often a lack of policies on how to manage the content of corporate wikis and who should be allowed to correct the information submitted by others (Standing and Kiniti 2011).

5.4.2 Format for reuse

When searching for information about technologies, engineers will hope to find e.g. test reports and guidelines that can be applied easily to the specific problems they want to solve. In the best case, they are able to find relevant information about how technologies operate in the same environment as the problem at hand, or otherwise with clear instructions concerning the conditions under which the information is valid. For most organizations, a likely scenario would be for engineers to ask colleagues about how to find a report on how the technology was applied to a previous case. They would then have to investigate the differences vis-à-vis the current application and contact the members of previous project to recollect their previous work. Such investigations are time consuming and require a lot of redundant activities to catch up with the knowledge that was once at the fingertips of an entire project group. As an alternative, one could leverage the momentum of knowledge built up when developing the technologies in the first place by preparing them for a broader range of requirements and applications upfront.

A recurrent comment on how to make codified knowledge reusable is to capture its rationale (Busby 1999; Duffy et al. 1995; Markus 2001). Design rationale includes the justifications for a design, alternatives considered, evaluated trade-offs, and other argumentation (Lee 1997), which explains the ‘why’ of a previous design and supports the evaluation of how conditions may be different when that knowledge is reapplied in a new context.

A knowledge format dedicated to support simplified reuse is “Design Patterns”. It is common for standardizing on an abstract level how to design software architectures and software components (Schmidt 1995). Even if the code needs to be different in a new application, the structure of that code and the approach to solving a typical problem in software development can be recorded as a sort of best practice for reuse. Another example of the use of patterns is proposed by (Cloutier and Verma 2007) who apply the concept to the design of systems architectures. A collection of patterns can be used to specify in a generic manner the design and design process for different types of systems. The concept can likely be extended to technologies, where the application of a technology is described in an abstract or decontextualized manner. This type of activity to abstract and generalize knowledge can “extend the utilization capabilities of knowledge in a design by re-use process as they promote the flexibility of experiences by removing highly specific details.” (Smith and Duffy 2001).

6 Illustrative cases

To demonstrate the application of the framework and the twelve identified principles, a case regarding a real technology development project is used. The example comes from Mycronic AB, a company in Sweden that develops manufacturing equipment for the electronics industry.

6.1 Development of a new heater technology

A new heater feature was needed for the Mycronic MY600JD jet dispenser platform. The MY600JD is a system that jets fluids on-the-fly at high speed. A typical application of the system is to dispense surface mount adhesives for the purpose of underfill on a printed circuit board (PCB). Using an integrated heating unit, the material viscosity of the glue can be adjusted to optimize dispense results. The feature was derived from the product roadmap in an initial analysis. The general principle of heating the PCB to improve the flow of the fluid under the component was in use in the industry, so high-level conceptualization could be made by observing the competition. Heaters for this type of application have been around since the 1960’s, so in the external world, the technology was already at its maximum maturity of TRL 9.

The current TRL of this technology within the company was assessed to be 2. The required internal gate criterion for entering the next phase in the product development model was set at TRL 5 and hence stipulated the target.

The best strategy for closing the gap would be to acquire the technology from outside the firm. This highlights an interesting dilemma, being that other companies possessed the capability to make heaters for dispensing equipment, but it was considered unlikely that this capability could be transferred unless there was an alliance that facilitated an exchange of knowledge between Mycronic and a competitor. The remaining options were to perform research and development in-house, and as a backup initiate a search for neutral partners with applicable knowledge. The high maturity level of the technology in the external world increased the probability that the latter goal was achievable. Another aspect of the external technology assessment was the risk of it being protected by patents.

The project had been running for about a year when a reassessment identified the heater as a larger technology gap than originally anticipated. The scope, represented by the number of engineering domains being investigated from start, was limited to one: the heater element itself. The technical complexity of the system was thus regarded as low. However, detailed investigations of the design exposed additional interfaces to the rest of the system. This suggested that researching the heater itself would not suffice to reach the desired outcome. In addition to providing heat, which obviously was the main function of a heater, the scope was extended to include positioning errors caused by temperature expansion of system components, impact on vision and cameras due to air lensing, accelerated material deterioration in cables and lubrication from heat exposure, and finally the change of atmosphere and outgassing in system affecting sensors. The total number of required technologies in the architecture was now up to five, thereby significantly increasing the level of technical complexity. This increase in complexity substantiated that the introverted research was extended to span across far more disciplines than was anticipated, thereby affecting project process and coordination.

The remaining time until the capability was needed was only about a year and it became apparent that the pace was too low to meet the deadline. To catch up, the project would have to be classified as time-critical. While increasing the probability for gap-closing success, executing in time-critical mode has downsides, mainly in terms of harm to other competing projects. The organization would have to dedicate staff to this particular project only, thereby limiting the flexibility of the workforce. The personnel would be selected for specific skills and experiences, sometimes to the potential detriment of other projects. The schedule would be put under tight monitoring by management for early detection of deviations from plan, typically at the cost of increased overhead. Exposed to the consequences of rushing the project, management decided to postpone the product development.

6.2 What if the framework had been used?

The self-assessment scorecard in the appendix was used in a retrospective study of the heater case to better understand what factors of the framework would likely have been beneficial to project. The case is discussed by walking through the factors and practices that yielded the highest expected influence of the project outcome.

Reviewing the practices, it can be observed in the description above that there was some sort of technology and product roadmap in use. However, none of the reuse strategies identified in this study were present at the company at the time, and hence the project did not develop the technology for future reuse, and nor did it assessed its reuse potential. The side effects from heat sources on positioning, vision, aging, and outgassing, were all known issues of products from a different business unit of the case company, but the knowledge was not shared across organizational boundaries and could, therefore, not be reused.

Regarding principles relating to technology process, it is clear that the company to some extent separated the technology development from the product development. However, as could be identified in the later stages of the project, an isolated development failed to incorporate all perspectives and interdependencies within the product where the new technology where to be inserted, which had a negative effect on the schedule. As a consequence, the temporal separation of technology and product development shrunk to the point where a delay was unavoidable. While the initial technology readiness of the heater was accurately assessed, the reusability of the external application in the new context was severely overestimated. The company failed to appreciate the complexity of the integration and consequently did not adapt the plan to match the degree of difficulty for advancing the technology from TRL 2 to TRL 5.

When it comes to the culture of creating reusable assets, the case company did strive to explore new technology beyond the scope of the current application, e.g. by providing trade-off and limit curves of its performance. However, the scope was limited to the reuse of technology across product generations rather than across product families. This exploration indicated how far a technology could be stretched to meet the requirements of future products in the roadmaps and when a new technology must be available to replace it. Design by reuse was further limited by the lack of knowledge sharing across product families as was discussed earlier. Occasionally, the knowledge created in technology development projects was captured and shared in seminars and through the publication of visual posters describing the problems at hand, but at the time of the heater project, the knowledge management was not conducted in a structured way and was not prescribed by business processes. There were only moderate interactions between domain experts outside the project staffing and the introverted perspective on the heater integration was likely a contributing factor to the late discovery of the interdependencies with other engineering disciplines. The expertise existed in other parts of the organization, but never reached the project team due to lack of personalization or codification of knowledge.

The information technology for storing and administrating knowledge was very heterogeneous at the time of the heater project. Results and experiences from past projects could be found in multiple repositories and systems such as Lotus Notes databases, Confluence wiki-pages, a SmarTeam PDM system, and plain file servers. The format did not follow any particular template suitable for reusability, and searching through the repositories required dedicated search engines for the individual systems. It is clear that the case company would benefit from a more structured way of managing knowledge to facilitate its creation, capture and reuse, and where applications such as heat source implications on precision instruments serve as a proof of this need.

7 Discussion

In this chapter, the principles of the framework are discussed in the context of future use and difficulties relating to technology reuse in general.

7.1 Implications of applying the framework

Practitioners who want to improve their companies’ effectiveness in the repeated application of technologies can use the twelve practices included in the framework to identify areas that are in need of improvement. Most of them are well known to practitioners, at least in principle, but the packaging into a coherent framework will support the conversation on how to establish a reuse capability.

7.1.1 Survey

As an illustration of the method in use, Fig. 7 shows two charts that visualize the results from two different assessments that were completed by employees working with improving technology and knowledge management practices at Company A and B, respectively. Both companies develop and manufacture products with advanced technologies and have an international presence. The assessors completed the assessments based on the business units with which they were most familiar to extract meaningful results.

Fig. 7
figure 7

Two charts from completed assessments at Company A and B respectively, where the coloured boxes represent the questions in the assessment and their positions indicate their scores in the dimensions relevance and performance

Full size image

The charts show that most practices were believed to be relevant or highly relevant to their business units, and that there was a large variation of their performance. When comparing the results, it is for instance clear that the respondent from Company A gave lower performance scores on questions relating to culture and IT than did the respondent from Company B. Since the measurement is subjective and only provided by one employee from each company, the differences could be related to differences in the perception of the assessors, such as expectations or quality of information about the unit, or actual company performance. Inter-company comparison from different assessors could be highly useful as a way to encourage discussions about differences in perception and priorities to support decisions on how to develop the practices of the organization.

7.1.2 The illustrative cases

The illustrative cases show that the framework has the potential to facilitate decision-making and highlight potential problems, such as over reliance on existing technology or untested assumptions.

7.2 Dependencies between the principles in the framework

The practices operate at different levels in the organization and there are some dependencies among them that are useful to acknowledge. For instance, to benefit from the practice to ‘design by reuse’, there should be assets available that are ‘designed for reuse’ and preferably ‘formatted for reuse’. In addition, without a strategy to develop technologies for multiple applications (‘technology platform strategy’), it can be difficult to acquire internal funding for setting ‘goals for exploration’ rather than just developing technologies for the applications at hand. An analysis by the authors of what practices have a direct positive effect on other practices is provided in the Dependency Structure Matrix (DSM) of Fig. 8, where cell (1.2; 1.1) indicates what effect practice 1.2 has on 1.1, etc.

Fig. 8
figure 8

Dependency structure matrix (DSM) over the twelve principles of the framework. Reading along a row shows what other practices have a positive effect on a particular practice, and vice versa

Full size image

The DSM in Fig. 8 indicates that some practices can be greatly improved by the existence and performance of other practices. ‘Design by reuse’, which is affected by all the other practices, would require a comprehensive reuse capability in general to be leveraged to a great extent.

7.3 Managerial and engineering implications

There are many other factors to take into account when deciding on how to prioritize and implement practices in an organization, such as the effort necessary to introduce them or what role technology in general has for the business. This research has attempted to make a contribution by studying implications of technology reuse primarily at the engineering level, with a particular focus on existing challenges for the effective reuse of technology in new applications.

Organizational culture was not explicitly studied as a dimension of the empirical part of this research, but it is clear from the literature that it plays an important role in knowledge transfer. It has been stated as one of the most important factors for successfully transferring knowledge (Davenport and Prusak 1998) and succeeding in introducing knowledge repositories, especially for collaborative repositories, such as Wikis (Standing and Kiniti 2011). Based on our interviews and discussions, the case company seems to find itself in an early stage of the transformation into a culture of knowledge sharing. The general impression from the interviews conducted was that there were no signs of active resistance, such as knowledge hoarding or unwillingness to share knowledge when asked for it. However, there was low transparency, as well as lack of incentives, internal and external, for making an effort to make new knowledge readily accessible. Since the mind-set of prioritizing future reuse needs to be infused along with the methods, this presents a challenge for the adoption of new methods for knowledge capture and sharing.

7.4 Implications on innovation

Technology development as a strategy is tightly connected to innovation and creating new products with higher performance and practical use. However, reuse strategies can often be said to be counterproductive to innovation since they favour incremental development of existing technologies. Each reuse decision must be taken in the context of this trade-off. However, making an informed decision regarding the risks of reuse and the risk and cost of developing new technology would always benefit from being based on factual evidence. Sometimes it will be more efficient to reuse an existing technology and sometimes the market will require a new technology to be developed in order for the business to stay competitive. By setting goals for exploration, the limits of a technology can be better understood so that the search for new technology can commence at an early stage. Supported by long-term planning, such as technology roadmap techniques, it becomes possible to consider more radical designs associated with a higher level of risk, thereby achieving a better balance between reuse and innovation.

8 Conclusion

Reuse of technologies within companies is so natural that it risks being overlooked as a potential area in need of a systematic approach. In the literature, there is more to be found about knowledge management in general, as well as concepts for reusing components, software, and manufacturing systems. The approaches for reusing technologies have not been defined to the same level of detail, and most frameworks for reuse have focused on the stages in which knowledge is integrated into a new application rather than how to create an infrastructure that fosters the reuse capability from a systems perspective.

This paper contributes to the research area of technology reuse by presenting an overview of literature from several different research fields that relates, directly or indirectly, to the reuse of technologies. A framework was developed, based on this literature study, which features twelve practices supporting a technology reuse capability, which where categorized into four areas of success factors: Strategy (Platform Thinking), Process (Supporting Technology Integration), Culture (Creating Reusable Assets), and Information Technology (Managing Knowledge). This research has provided a questionnaire available for self-assessing the approaches used by an organisation to identify their reuse practices. A detailed case was presented regarding the practical difficulties of technology reuse.

The purpose of developing the framework was to provide an overview of ways in which organizations can improve their capability to reuse technology. The framework includes practices that range from a strategic to an operative level, but it does not go into depth to prescribe how to design or implement them. Instead, it presents as a starting point for identifying and discussing what practices need more attention. To illustrate how the framework can be used in practice, a self-assessment scorecard with evaluation questions for each of the twelve practices was provided and demonstrated with responses from industry.

Further, a case study was used to evaluate the approach from a retrospective perspective, and a discussion follows of how the principles could have been used to better foster technological reuse. As it turned out, most principles were relevant for the case, and the lack of communication and collaboration regarding technological knowledge cross product lines was especially evident, i.e. a technology reuse strategy was lacking at the time of development. Further retrospective case studies could help validate the framework. A future study evaluating the implementation and application of the framework in industries that are known to be highly proficient in the reuse of technology with others that are less proficient, could show if the framework can capture important differences in underlying factors, or if the framework can be extended to include them. The framework in its current form will be useful to inspire practitioners and academics to continue to develop theory on technology reuse capability with a systemic perspective, as well as raise awareness of its multifaceted nature.