Assessment of Readiness for Internal Technology Transfer

– A Case Study

Daniel Corin Stig Product and Production Development Chalmers University of Technology

412 96 Gothenburg, Sweden corinsti@chalmers.se

Ulf Högman Product and Production Development Chalmers University of Technology

412 96 Gothenburg, Sweden ulf.hogman@chalmers.se

Dag Bergsjö

Product and Production Development Chalmers University of Technology

412 96 Gothenburg, Sweden dagb@chalmers.se

Copyright © 2011 by Daniel Corin Stig, Ulf Högman & Dag Bergsjö. Published and used by INCOSE with permission.

Abstract. Premature introduction of new technologies in product development is likely to lead to both budget and schedule overruns. The assessment of when a technology is ready to be transferred from technology development to product development and production is critical for striking the right balance of short time-to-market and low risk. Previous research on internal technology transfer has mainly focused on the development of methods and tools for assessing technology readiness for major development programs in governmental agencies, revealing few cases of such implementations in technology driven industrial companies. This paper aims to provide description of experiences from using such tools at a case company and prescription on how to manage the identified challenges. The study is based on 22 semi-structured interviews, primarily with personnel from the technology and product development departments. The results indicate that the readiness assessments suggested in literature can support decisions also in industrial companies. However, adapting the tools to the internal differences between technologies is important for minimizing administrative workload and ensuring implementation readiness as opposed to just technology readiness. The strategy for their adaptation could benefit from more research on the practices of companies dealing with internal technology transfer and from the development of a framework for how to adapt the assessment process to different contexts.

Introduction A common cause for delays in product development is premature introduction of new technologies (Eldred and McGrath 1997a). In order to reduce the risk of delays and cost overruns, technology development efforts are often run in separate projects to prove the feasibility of the technology before deciding on implementation in products and production. Transferring the knowledge acquired during technology development to the users in product development and production has proved to be a challenging task (Malik 2002), which needs to be managed with a structured process (McGrath 1996; Nobelius 2002; Cooper 2006). Current research on technology transfer deals with a number of distinct topics. In an

attempt to clarify the taxonomies, Steenhuis and de Boer (2002) suggest that technology transfer could be divided into innovation (from research to products), exnovation (industrializing countries catching up with the industrialized) and international (between countries, mainly production-related). This paper focuses on the first, innovation, and especially the internal transfer from technology development to product development and production within a company. The literature on this company-level subtopic of technology transfer is closely related to product development management, knowledge management and systems engineering and has been published in a wide range of conferences and journals. This paper aims to follow the examples of e.g. Eldred and McGrath (1997a and 1997b), Malik (2002), Nobelius (2002) and Magnusson and Johansson (2008) by studying internal technology transfer in industrial companies. A considerable part of the publications in this field, however, are derived from major governmental development programs run by defense and space agencies (e.g. Bilbro 2007; Mankins 1995; Sauser et al. 2006; Altunok and Cakmak 2010), and deal with how to ensure transfer success by monitoring technology readiness. The adoption and adaptation of these methods in industrial companies relying on new technology for their success constitutes an interesting field for extending the research. This paper aims to explore this transfer process at a supplier in the aircraft engine industry and discuss potential improvements to their processes.

Frame of reference Technology development. For this paper, technology development is defined as the dedicated development activities of a company that precede product development and production with the purpose of minimizing the uncertainty and risk of integrating new technologies in existing or forthcoming systems. It corresponds to what Nieto (2004, 315) calls the technological innovation process: “a learning process through which a flow of new knowledge competencies and capabilities is generated” and is sometimes referred to as advanced engineering or applied research. Being fast and effective in developing new technologies and products has become an important competitive advantage (Katz and Allen 1985; Wheelwright and Clark 1992; Eldred and McGrath 1997a; Trott 2008), but the development of new technology is often mismanaged and the efforts fail to produce the intended benefits (Eldred and McGrath 1997a; Cooper 2006; Roberts 2007). Solutions presented in literature include finding the right organizational structure, choosing an appropriate level of formalization in the processes and improving the downstream transfer to product and process development (Szulanski 1996; Cooper 2006; Roberts 2007).

Technology transfer. Eldred and McGrath (1997b) state that the transfer from technology development to product development does not occur naturally since the two processes differ in many ways. They discuss three important dimensions of the transfer activity; program synchronization, technology equalization and technology transfer management. Roughly, these cover the timing, content and management aspects respectively of technology transfer. In an optimal timing of transfer, the technology reaches its required readiness level at the same time as the subsequent product development projects are ready to receive the results, which is normally when the product concept has been approved (Eldred and McGrath, 1997b). According to Magnusson and Johansson (2008), this decision on transfer timing should be a balance of short time-to-market and low technology risk in product development. There are many different categorizations of the content to be delivered in technology

transfer processes. Rebentisch (1995, 2) used the categories general information, specific information, procedures/practice and hardware when studying technology in a joint venture. A similar classification is used by Nobelius (2002), who also divides it further into blueprints, prototypes, persons, methods, procedures, test results, alternative concepts, supplier suggestions, engineering reports and lessons-learned books. In the Nobelius study (2002) study the main type of content in the reviewed technology transfers was technical results, while the type containing most shortfalls according to the receiving product developers was implementation-oriented information. A similar observation is made by Eldred and McGrath (1997b, 30) who state that product developers often perceive the results from technology development as insufficient for “evaluating and enabling the technology”. Howells (1996, 97) discusses tacit knowledge in the context of innovation and technology transfer, and states that “tacit knowledge is difficult to codify and it is usually part of a long-term, accumulated learning process that often starts a more systematic scientific understanding of a technology or process”. This is in line with what several other authors have pointed out about knowledge transfer being a continuous process rather than a one-shot event (Leonard-Barton 1995; Szulanski 2000; Cummings and Teng 2003). Cummings and Teng (2003) also argue that both transferring parties need to be involved in the process to improve the recipient’s commitment to the knowledge. In an attempt to predict the type of transfer process needed for a certain technology, Stock and Tatikonda (2000) have created a model that uses technology uncertainty as input to suggest an appropriate level of interaction between the source and the recipient (see Figure 1). The lowest level of technology uncertainty would advocate a transfer process called arms-length purchase that involves low interaction between the transferring parties, followed by facilitated purchase for higher uncertainty, then collaborative hand-off and finally co-development which is the highest level of interaction for technologies with very high uncertainty. Stock and Tatikonda (2000) define three dimensions of technology uncertainty: novelty, complexity and tacitness. Novelty is related to the amount of prior experience and change involved, complexity is defined as the technology’s interrelatedness and scope, and tacitness is the extent to which knowledge about the technology is embodied in physical resources.

Figure 1 Choosing the level of interaction in the transfer process. Source: Stock and Tatikonda (2000)

Technology readiness assessment. By measuring the maturity of a technology, one can estimate the risk and cost of further development and decide when it is ready for transfer to product development (Nolte 2008). The most widely adopted metric for assessing technology maturity is the scale with Technology Readiness Levels (TRLs) developed by NASA (Mankins 1995) where higher levels indicate a more complete prototype and higher level system verification. Figure 2 presents a short version of the definitions for each level.

However, the metric has been criticized for being e.g. subjective, inaccurate and poorly defined, and thereby having limited value when it comes to supporting specific decisions (Cornford 2004). The confusion around definitions is also discussed by Tetlay and John (2010), who argue that the terms maturity and readiness should not be used interchangeably. They suggest that system readiness relates to the validation of the solution to the user specification, representing the top tier in the V-model, while system maturity is the verification to system specifications, which is on the second highest level of the V-model. In this paper, however, the terms maturity and readiness are used interchangeably. Further, as shown in a study by Nobelius (2003) from the automotive industry, technology readiness is not necessarily perceived as the same thing as preparedness for product development. When comparing two different team structures for technology development, he found that one structure produced higher perceived technology readiness but lower preparedness for product development at the time for transfer than the other. To avoid insufficient preparation, contingent approaches have been suggested where the transferring and the receiving department must agree on what defines feasibility for the specific situation (Burgelman et al. 2009; Eldred and McGrath 1997a). The uncertainties derived from interrelatedness of technologies have been addressed by Sauser et al. (2006), who propose a separate readiness metric called Integration Readiness Level (IRL) to be used together with the TRL metric to define the readiness of a system, in turn measured with a System Readiness Level (SRL). Mankins (2009b) points out three types of information that are important when making R&D investment decisions; the current level and goal for maturity, the

Figure 2 Overview of NASA’s technology readiness scale. Source: Mankins (2009a)

difficulty of reaching higher maturity levels and the importance of the technology to the overall goals of R&D. Mankins (2009b) suggests the use of an integrated tool for assessing these three factors in a risk matrix that is illustrated in Figure 3. The matrix combines (1) the TRL scale, (2) a five-step scale called Research and Development Degree of Difficulty (R&D3) for the difficulty of further development and (3) a five-step scale for the importance of the technology called Technology Need Value (TNV). The R&D3 metric has been employed at NASA (e.g. Hall 2004) and is used as an element in other models and frameworks for making technology assessments (Kirby and Mavris 2002; Mahafza et al. 2005).

Figure 2 Mankins’ Technology Risk Matrix. Source: Mankins (2009b) Similarly, Bilbro (2007) has proposed the use of two metrics when performing technology assessments; NASA’s TRL scale and a nine-level scale called Advancement Degree of Difficulty (AD2). AD2 is similar to the R&D3 metric in that they both measure the required efforts for further maturing a technology, but uses a more systematic approach for determining the difficulty level. For further reading, a summary of different scales of readiness levels (xRL) and maturity assessments is presented in Azizian et al. (2009) and the most common ones are listed in Table 1.

Table 1 Common metrics for assessing technology readiness

Abbreviation Metric Reference TRL Technology Readiness Level Mankins 1995 IRL Integration Readiness Level Sauser et al. 2006 SRL System Readiness Level Sauser et al. 2006 TNV Technology Need Value Mankins 2009b R&D3 Research and Development Degree of Difficulty Mankins 2009b AD2 Advancement Degree of Difficulty Bilbro 2007 As seen in the literature reviewed above, there are multiple suggestions on how to approach readiness assessments in order to minimize risk and make the transfer of technologies to product development as seamless as possible. This paper aims to contribute to this research field by describing the experiences of a company that is

using technology readiness assessments to support internal technology transfer and by prescribing ways to manage the identified challenges. The following research questions were stated:

RQ1: What are the most important factors for determining the timing and content for internal technology transfer at the case company?

RQ2: How can these factors be addressed in the methods for assessing technology readiness?

Method By examining technology transfer at one specific company to improve the understanding of current practices and make way for improvements in related processes, this study has a mainly inductive approach (Bryman and Bell 2003). A flexible research strategy with a single case was used (Robson 2002), gathering the data from 22 semi-structured interviews (see Table 2), document analysis and recurring informal discussions with technology and product development personnel at the case company. This enabled the researchers to examine the highly contingent context in which technology development is performed and the difficulties experienced by people involved as regards ensuring a successful technology transfer. A majority of the interview material was reused from a previous study on technology transfer at the case company performed by Bengtsson and Stetz (2009), covering all types of technologies. The additional interviews were then performed in 2010 and focused on new manufacturing methods, as these were in majority and regarded as the most difficult technologies to transfer. While many of the findings are valid for all types of technologies, this has clearly affected what issues are emphasized in the observations and the types of documents being transferred. The recordings from all interviews were transcribed and relevant statements extracted and categorized. Technical documents and process descriptions from technology development were also studied in order to complete the picture derived from the interviews and to gain more thorough insight into the development activities.

Table 2 Role and department of interview subjects

Department Role Product development (12) Project manager (8) Technology development (6) Production engineer (5) Other (4) Design engineer (4) Other (5)

Results The empirical findings are presented in this chapter starting with an introduction to the case company and its development process. This is followed by a summary of the results from the interviews and reviewed documents, divided into three aspects of internal technology transfer; content, timing and management.

The case company. The case company develops and manufactures components and sub-systems for aircraft engines. The products are complex and require extensive development as well as rigorous testing and documentation to be certified by regulatory authorities. The benefits from offering lightweight, cost-efficient and robust solutions are high, which stimulate efforts to constantly develop new platform technologies with such as altered materials and new manufacturing methods. The

complexity of the products and the high uncertainties in the early stages of development result in long development lead-times and high requirements on verification, which in turn puts great demands on efficient development processes to improve e.g. innovativeness, time-to-market and traceability. The case company has built their technology development process around NASA’s TRL scale by using the first six levels as gates in a stage-gate process. Each level is accompanied by a checklist of deliverables that should be presented to the review committee at gate reviews. The last three levels (TRL 7-9) have been left out, since they are not reached until product development, which has a separate gated process. In order to better comply with the unique deliverables for manufacturing technologies, an adapted list has been set up for those at the initiative of the manufacturing development personnel. Similar needs inspired the U.S. Department of Defense (DoD) to define a dedicated scale called Manufacturing Readiness Levels (Department of Defense 2010a). In contrast to the fully tailored checklist of DoD, the adapted checklist used at the case company only differs on a few items as compared to their standard checklist employed for other technologies.

Transfer content. When project managers were asked about what was delivered from technology development projects, they were unable to give a comprehensive answer. Instead, they often referred to the internal checklist for TRL 6, stating what should be accomplished to qualify for transfer to product development and production, or some of the items therein. However, due to the generic nature of the checklist its items are expressed in relatively wide terms. The deliverables mentioned throughout the interviews were in most cases examples from the headings of either the TRL checklist, the functional specification or the implementation plan, all three of which are commonly specified as expected results in the directives for technology development efforts. The TRL checklist and the project directive were seen as the documents giving the best guidance to what should be delivered, and from analyzing the documents it was clear that TRL 6 is a common result specified in the project directives. When interviewees, both product and technology developers, were asked what they considered being the most important result from technology development, the most common answers were a robust and verified method and cost-efficiency. If the methods were not regarded as robust, they would bring too much uncertainty to the implementation stage, and without verification they do not achieve the needed certifications from authorities and customers. Cost-efficiency was often one of the driving forces behind the whole introduction of the new technology, and without a firm business case there would be no point in changing the current practice. The documents most often mentioned as transfer content were implementation plan, education plan, method specification, acceptance specification and equipment purchase specification. Currently there is no formal routine for what documents should be created for a technology development effort, but there are plans to introduce a list of recommendations. A summary of the most common contents mentioned during the interviews is provided in Table 3.

Table 3 Summary of interview comments on transfer content

Documents specifying project goals

Most important deliverables

Most important documents in delivery

TRL checklist Robust method Implementation plan Project directive Verified method Education plan Cost-efficiency Method specification Equipment purchase specification

The process of transferring technologies to product development and production is not formally defined at the case company, and the common view has been that the endeavors of the technology development personnel end at the project closure with the achievement of TRL 6. According to the interviews, however, it is essential that key members from the technology development team are involved at least until TRL 7 to ensure a successful implementation. Cases were mentioned by a few interviewees where a technology was transferred to production for implementation, and the absence of members from the technology development team resulted in substantial loss of momentum in the progress. Without background knowledge, some of the previous work had been repeated by the recipient due to both lack of trust in the rationale for earlier decisions and lack of competence for how to manage issues that appeared during implementation and ramp-up. Apart from the transfer content mentioned above, there were also suggestions made during the interviews about deliverables on a more detailed level that are important and risk being overlooked in the development projects. These were mainly related to practical issues regarding preparations for implementation and are listed below:

Holding seminars to spread knowledge Allocating room in budget for equipment purchase Being represented when product concepts are chosen Tacit background knowledge about previous decisions and lessons learned Managing changes in salary following education and increased responsibility

of production personnel Preparation for future levels of automation Identification of current methods that can be replaced by the new one Human safety issues Preparations for certifying and registering new equipment in the inventory list Requirements on the production cell Ensuring that process output meets requirements at full rate production Building competence in production

Timing of transfer. A robust and verified method was seen as the most important transfer object, and the time at which this can be achieved is the time to synchronize with the receiving product development projects. In the reviewed project directive documents, it was written into the goals that the TRL 6 review should be passed at a given date or month, giving an expected delivery time for the product development projects. However, according to the interviews, the completion date for technology development was not always tied to a delivery date, as the recipient was not always decided. Because the product development projects were regarded as more highly prioritized with more resources and sharper deadlines than technology development, they sometimes waited with committing to technologies that were not critical for the realization of the product until they knew how well the technology would meet its timing and performance targets. Critical technologies, on the other hand, were typically given additional resources to catch up with the schedule if they were running late, due to e.g. unexpected events or changing requirements from the customer. One of the interviewees stated that complex technologies need a higher TRL to be ready for implementation, but this suggested solution to premature technology transfer was not reflected upon during any of the other interviews.

Transfer management. From the definitions of TRL levels found in Mankins (1995), the case company made their interpretation of what criteria to use for the assessment,

resulting in a 33-item checklist for each of the first six levels. The checklists worked well according to the interviewees, but some were concerned that the criteria in some cases could be too vague. They mentioned cases when reviews had failed to highlight technology immaturity, with resulting delays in the subsequent product development project. Especially implementation related criteria were subject to being overlooked during TRL reviews as focus was given mainly to assessing the technical feasibility of the technologies. When interviewees were asked if a more extensive checklist would be beneficial to reduce the risk of letting immature technologies through the reviews, a concern was raised about the workload of administration. Too many requirements on administration with checklists, metrics and documents would inflict additional costs and could even make it impossible to get a positive return on the small technology development projects, sometimes less than a man-year in size.

Discussion Using the same sections as in the previous chapter, the findings from the case company are discussed here with support from the literature presented in the frame of reference. The challenges and considerations for transferring technologies are presented in conjunction with possible solutions, while in the conclusions the two will be separated in order to answer the two corresponding research questions. In the final section of this chapter, there is a discussion about the reliability and validity of the results and about possible future work.

Transfer content. The interviews showed a consensus about the expected deliverables from technology development, and the focus was on producing a set of documents proving feasibility through test results, specifying how to replicate the results in production, defining requirements on equipment and planning for implementation. Some of the interviewees emphasized the importance of transferring personnel to subsequent activities for providing the tacit knowledge acquired during development to support implementation. This is also found in the deliverables mentioned by Nobelius (2002), but is not covered in the categories by Rebentisch (1995). The transfer of tacit knowledge is a hot topic in the field of knowledge management, and many authors agree that substantial interaction is required between the source and the recipient in order to be successful. This suggests that either an extended overlap between the projects or a transfer of personnel is necessary, but which strategy the case company has chosen, formally or de facto, is not clear from the results of this study. The list presented in the observations chapter of various deliverables that risk being overlooked signals that the use of TRL as a metric for assessing transfer readiness may be insufficient in some areas. Even if the checklist used at the case company has been complemented with some implementation related criteria as compared to the original TLR definitions, the developers still perceive technologies to be the least ready in those aspects at the time of transfer. The same phenomenon was found in the Nobelius study (2002) on the automotive industry and it can probably not be fully attributed to insufficient checks in the gate review. In this case, part of the explanation may lie in the fact that some of the technology development projects target a possible application rather than a sharp one. Thereby they become more focused on proving feasibility than preparing for implementation, since the latter would become sunk costs if the technology would not be introduced in the new product.

Timing of transfer. The recommendation from Eldred and McGrath (1997b) that technologies should be ready for transfer around concept selection in product development does not necessarily fit with the perception that TRL 6 is a suitable measure for that readiness. Although only one of the interviewees questioned the assumption, it is unlikely that all technologies can be considered equally mature after “System/subsystem model or prototype demonstration in a relevant environment“ (Mankins 1995, 1). As a complement to the TRL scale, Mankins (2009b) has addressed this difference between technologies at the same TRL from the aspect of how difficult it will be to reach operating conditions. The magnitude of the effort needed to move a complex technology from TRL 6 to higher levels obviously affects the perceived readiness of the technology for the recipients, since they need more resources to continue the development, often leading to an increased development time as well. The amount of work involved in preparing a technology for implementation is easily underestimated, which could also be part of the explanation for some of the cases, where such aspects were considered overlooked during gate reviews. Figure 4 below is a fictional schedule for technology transfer where the deadline of product development has been decided, and TRL 6 has been used to define transfer readiness. The timing of transfer has been matched to the concept gate as prescribed by Eldred and McGrath (1997b). The technologies A-C achieve TRL 6 at the same time, but the time needed for moving from verification in representative environment (TRL 6) to operating environment (TRL 9) differs. If case B is taken as the preferred timing of achieving TRL 9, case C will create a delay to product launch, while case A could have been introduced later without negative consequences.

If gate decisions are to reflect implementation readiness rather than technology feasibility, a standardized measure of difficulty such as the R&D3 (Mankins 2009b) or AD2 (Bilbro 2007) could be beneficial for management in giving decisions at gate reviews. If TRL 6 is used as the measure for transfer readiness, the deliverables required at that level must correspond to the amount of preparations that need to be made to enable the transfer to be completed and performance targets to be reached within schedule for the subsequent activities as in case A and B of Figure 4. Hence, instead of requiring a higher TRL for transfer readiness of complex technologies as stated in the interview, a more accurate definition of TRL 6 or complimentary measures that address the complexity and difficulty could be a solution to the problem of premature transfer at the case company.

Transfer management. The case company has made their own interpretation of the TRL scale in the form of gate review checklists. Similar clarifications of the criteria for achieving TRLs have been made by e.g. DoD for their MRL scale (Department of Defense 2010b) and in the TRL calculator described in a white paper by Nolte et al. (2003). However, the conversion from a general definition of a readiness level to a formal procedure for guiding development is dependent on thorough knowledge about

Technology Development

Product Development

TRL 6 TRL 9A TRL 9B

TRL 9C

Figure 4 Effects from the level of difficulty of further maturation after TRL 6

Case A Case B

Case C

the contingency factors affecting technology introduction in the specific case. Some criteria are probably recurrent in most situations, e.g. repeatability in testing and education of machine operators, but it is not easy to find the balance of a comprehensive yet manageable set. The metrics for readiness assessment presented in the frame of reference use generalized criteria and give the impression that they work for all technologies. If the scale against which the judgment is made is described in wide terms, it is also prone to interpretation and subjectivity, which was one of the shortcomings pointed out by Cornford (2004). Consequently, those who use these scales must rely on their qualitative judgment for correct assessments. A checklist item such as “Analysis and testing of representative components” that is found in one of the case company’s TRL definitions still requires an interpretation of what “testing” and “representative” mean in the context. Tempting as it may be, by adding more criteria and increasing their resolution the administration may become too heavy. A company that needs to balance the level of formalization over a heterogeneous project portfolio may benefit from another approach than using a fixed set of tools and processes for technology assessment and transfer. Two possible solutions for addressing the differences are flexibility and multiple editions. The former may be accomplished by requiring that the development teams and the gate reviewers or the recipients interpret the gate criteria in advance as recommended by Burgelman et al. (2009) and Eldred and McGrath (1997a). One such decision could be to ensure that one or a few team members continue working with the technology during product development if it is needed in that specific case. This can also give large or complex programs more requirements to be fulfilled before passing the criteria and vice versa. Hence, flexibility can be used both for increasing the resolution of the readiness definition by adapting it to the unique circumstances of different technologies and to adapt the bulk of review criteria to the needs of the project. However, if an extensive change to the readiness definition is needed to fit a small project, there is the risk that something is overlooked and the definition no longer verifies readiness. The second solution is to create separate editions of the review process and criteria checklists for different categories of technologies. With an already defined downscaled version for the smaller initiatives, only minor modifications would be needed. Regardless of which approach is chosen for managing projects with different characteristics, the creation of a formal guideline would make it easier to get feedback from the development projects and to work with continuously improving the process.

Reliability and validity of results. Since the empirical material was derived from a single case company, the results are not suitable for generalization. However, many of the findings were supported in literature regarding technology transfer, and the experiences from using TRL checklists at the case company could help prepare other companies for the challenges that lie therein. The focus on manufacturing methods in the in-depth interviews has certainly influenced the results, but the authors are convinced that most of the findings are, to a greater or less extent, relevant for all types of technologies. Other dimensions that have not been addressed, such as the difference between critical and non-critical technologies, are probably just as important. The findings indicate that the design of an effective process for managing the interface between technology development and product development can be supported by combining the research on knowledge management, technology transfers and technology readiness assessments. A recommended continuation of this field of study is to provide more experience of the use of technology readiness

assessments for the purpose of supporting technology transfer decisions in industrial companies. Together with existing literature, this can support the creation of a framework for how to design assessment methods depending on the characteristics of business environments and technologies to minimize the administrative workload, while improving decision support for technology introduction. The differences between internal technology transfers in governmental agencies and industrial companies was assumed, but not analyzed, in this study, and it therefore remains to be explored what can be generalized between the two development contexts.

Conclusion The transfer process between technology development and product development has been addressed in many studies as a problematic area with strong impact on e.g. development cost, product quality and time-to-market. Adaptations of the TRL scale have been implemented in different settings to address this by assessing technology maturity to ensure correct timing of transfer. The two research questions stated for this paper are answered below.

RQ1: What are the most important factors for determining the timing and content for internal technology transfer at the case company?

TRL checklist is used to define the transfer content. A checklist was used to state the requirements for achieving TRL 1-6, where TRL 6 also served as the acceptance level for technology transfer, and the interviewees regarded the TRL checklist items to be the main operational goals for their technology development projects.

Difficulty of further maturation. In literature, the difficulty of further maturation has been addressed as an important factor missing in the TRL scale. Even if only one of the interviewees indicated that this metric is missing, it is a critical factor in determining transfer timing that has not been clearly addressed at the case company.

Interpreting the readiness definitions. Projects of different sizes and uncertainty are currently using the same readiness assessment process at the case company. The definitions leave room for interpretation, and while some ask for additional criteria to support transfer decisions, others are worried about overloading the projects with administration. Based on the interviews and the reviewed literature, relevant contingency factors for the projects include, but are not limited to, technology interrelatedness, previous experience, criticality, difficulty and cost of development.

Team members as a deliverable. According to some interviewees, an important transfer object is personnel to support implementation. Lack of background knowledge in subsequent activities had the potential of slowing down progress considerably, even if the recipients had been involved earlier during development.

RQ2: How can these factors be addressed in the methods for assessing technology readiness?

Flexible transfer readiness definition. Adapting the readiness criteria to each project could be a way of guiding the development efforts more effectively and to avoid discontinuity after transfer. Since the TRL checklists guide the content of transfer, these could be adjusted in advance to the technology being developed by the developers and the recipients as opposed to having only standard criteria.

Multiple gate review versions. Too much administration was noted as a hindrance for running small technology development projects, and an alternative or complement

to using the flexible approach is to have different versions of review criteria.

Measuring preparedness. If the objective is to measure implementation readiness as opposed to just technology readiness, it is important that the assessment process is complemented with criteria that address the distance to operational conditions in more dimensions than technical ones. In particular, it would be useful to highlight implementation-related criteria and to monitor the difficulty of progressing development after transfer.

Acknowledgements The authors would like to thank Daniel Bengtsson and Stefan Stetz for their work on technology transfer at the case company, and for sharing their interview material with us. The financial support from SPI, Areas of Advance - Production and VINNOVA (through the programs NFFP5 and Sustainable Production Strategies and Methods for Product Development) is gratefully acknowledged.

References Altunok, Taner, and Tanyel Cakmak. 2010. A technology readiness levels (TRLs)

calculator software for systems engineering and technology management tool. Advances in Engineering Software 41 (5):769-778.

Azizian, Nazanin, Shahram Sarkani, and Thomas Mazzuchi. 2009. A Comprehensive Review and Analysis of Maturity Assessment Approaches for Improved Decision Support to Achieve Efficient Defense Acquisition. Paper read at World Congress on Engineering and Computer Science, October 20-22, at San Francisco, USA.

Bengtsson, Daniel, and Stefan Stetz. 2009. Deliveries from Technology Development. MSc thesis, Chalmers University of Technology.

Bilbro, James W. 2007. Systematic Assessment of the Program/Project Impacts of Technological Advancement and Insertion. http://jbconsultinginternational.com/Doc uments/White%20Paper%20on%20Technological%20Assessment-Rev%20A.doc.

Bryman, Alan, and Emma Bell. 2003. Business research methods: Oxford University Press.

Burgelman, Robert, Clayton Christensen, and Steven Wheelwright. 2009. Strategic Management of Technology and Innovation. New York: McGraw-Hill.

Cooper, Robert G. 2006. Managing Technology Development Projects. Research-Technology Management 49:23-31.

Cornford, Steven L., and Liam Sarsfield. 2004. Quantitative methods for maturing and infusing advanced spacecraft technology. Paper read at Aerospace Conference, 2004. Proceedings. 2004 IEEE.

Cummings, Jeffrey L., and Bing-Sheng Teng. 2003. Transferring R&D knowledge: the key factors affecting knowledge transfer success. Journal of Engineering and Technology Management 20 (1-2):39-68.

Department of Defense. 2010a. Air Force Mantech MRA Questions. http://dodmrl.com/MRAT/MRAT_Questions_V10_4.xls.

Department of Defense. 2010b. Manufacturing Readiness Level Deskbook. https://acc.dau.mil/CommunityBrowser.aspx?Id=182129.

Eldred, Emmett W., and Michael E. McGrath. 1997a. Commercializing new technology--I. Research Technology Management 40 (1):7.

Eldred, Emmett W., and Michael E. McGrath. 1997b. Commercializing new technology--II. Research Technology Management 40 (2):5.

Gertler, Meric. 1995. "Being There": Proximity, Organization, and Culture in the

Development and Adoption of Advanced Manufacturing Technologies. Economic Geography 71 (1):1-26.

Gorschek, Tony. 2006. A Model for Technology Transfer in Practice. IEEE Software, 88-95.

Hall, Theodore W. 2004. Architectural Design to Promote Human Adaptation to Artificial Gravity. White Paper, NASA Office of Exploration Systems. http://www.spacearchitect.org/pubs/NASA-RFI-04212004-Hall.pdf

Howells, Jeremy. 1996. Tacit knowledge. Technology Analysis & Strategic Management 8 (2):91 - 106.

Katz, Ralph, and Thomas J. Allen. 1984. Organizational issues in the introduction of new technologies. Massachusetts Institute of Technology (MIT), Sloan School of Management.

Kirby, Michelle Rene, and Dimitri N. Mavris. 2001. A Technique for Selecting Emerging Technologies for a Fleet of Commercial Aircraft to Maximize R&D Investment. Georgia Institute of Technology.

Leonard-Barton, Dorothy. 1995. Wellsprings of Knowledge: Building and Sustaining the Sources of Innovation: Harvard Business School Press.

Magnusson, Thomas, and Glenn Johansson. 2008. Managing internal technology transfer in complex product development. European Journal of Innovation Management 11:349-365.

Mahafza, Sherry, Paul Componation, and Donald Tippett. 2005. A Performance-Based Methodology to Assess Department of Defense Technologies. Defense Acquisition Review Journal 11 (3):16.

Malik, Khaleel. 2002. Aiding the technology manager: a conceptual model for intra-firm technology transfer. Technovation 22 (7):427-436.

Mankins, John C. 1995. Technology readiness levels. White paper, NASA Office of Space Access and Technology. http://www.hq.nasa.gov/office/codeq/trl/trl.pdf.

Mankins, John C. 2009a. Technology readiness assessment: A retrospective. Acta Astronautica 65 (9-10): 1216-1223

Mankins, John C. 2009b. Technology readiness and risk assessments: A new approach. Acta Astronautica 65 (9-10):1208-1215.

McGrath, Michael E. 1996. Setting the PACE in product development: a guide to product and cycle-time excellence: Butterworth-Heinemann.

Mohamed, A. S., S. M. Sapuan, M. M. H. Megat Ahmad, A. M. S. Hamouda, and B. T. Hang Tuah Bin Baharudin. 2010. Modeling technology transfer for petroleum industry in Libya: An overview. Scientific Research and Essays 5 (2):18.

Nieto, Mariano. 2004. Basic propositions for the study of the technological innovation process in the firm. European Journal of Innovation Management 7 (4):314-324.

Nobelius, Dennis. 2002. Managing R&D processes - Focusing on technology development, product development, and their interplay. Ph.D. Diss., Chalmers University of Technology.

Nobelius, Dennis. 2003. Dedicated versus dispersed applied research organisation: implications for technology development and internal transfer to product development. International Journal of Technology Transfer and Commercialisation 1:249-267.

Nolte, William L. 2008. Did I Ever Tell You About the Whale?, Or Measuring Technology Maturity. Charlotte, North Carolina: Information Age Publishing.

Punter, Teade, René L. Krikhaar, and Reinder J. Bril. 2009. Software engineering technology innovation - Turning research results into industrial success. Journal of Systems and Software 82 (6):993-1003.

Rebentisch, Eric S. 1995. Knowledge in flux: the transfer of technology and practice in an international joint venture, Sloan School of Management, Massachusetts Institute of Technology.

Roberts, Edward B. 2007. Managing Invention and Innovation. Research-Technology Management 50:35-54.

Robson, Colin. 2002. Real World Research. Oxford, UK: Blackwell Publishers. Sauser, Brian, Dinesh Verma, Jose Ramirez-Marquez, and Ryan Gove. 2006. From

TRL to SRL: The concept of systems readiness levels. Paper read at Conference on Systems Engineering Research, at Los Angeles, CA.

Stock, Gregory N., and Mohan V. Tatikonda. 2000. A typology of project-level technology transfer processes. Journal of Operations Management 18 (6):719-737.

Szulanski, Gabriel. 1996. Exploring Internal Stickiness: Impediments to the Transfer of Best Practice Within the Firm. Strategic Management Journal 17:27-43.

Szulanski, Gabriel. 2000. The Process of Knowledge Transfer: A Diachronic Analysis of Stickiness. Organizational Behavior and Human Decision Processes 82 (1):9-27.

Tetlay, Abideen, and Philip John. 2010. Clarifying the Concepts of System Maturity, System Readiness and Capability Readiness through Case Studies. In Conference on Systems Engineering Research. Hoboken, New Jersey.

Trott, Paul. 2008. Innovation Management and New Product Development: Pearson Education.

Waroonkun, Tanut, and Rodney Stewart. 2008. Modeling the international technology transfer process in construction projects: evidence from Thailand. The Journal of Technology Transfer 33 (6):667-687.

Wheelwright, Steven. C., and Kim. B. Clark. 1992. Revolutionizing Product Development: Quantum Leaps in Speed, Efficiency, and Quality. New York: Free Press.

Biography Daniel Corin Stig, M.Sc., is performing research on technology development and knowledge transfer at the department for Product and Production Development at Chalmers University of Technology. He received his M.Sc. in Product Development (2010) and his B.Sc. in Industrial Engineering and Management (2008) from Chalmers University of Technology. Ulf Högman, L.Eng., is an industrial Ph.D. candidate at Chalmers University of Technology. He received his M.Sc. (1986) in Engineering Physics from Chalmers University of Technology and L.Eng. (2009) in Product Development from the same university. He has extensive experience from technology and product development in various companies operating in international environments. He has previously published research papers on, e.g., IAMOT, ICED, NordDesign, ASME Design Engineering Technical Conferences. His research has focused on processes and methodology for operational development of new technology in corporate environments. Dag Bergsjö, Ph.D., is Assistant Professor at Chalmers University of Technology. His PhD thesis covered the research area of PLM with particular attention on mechatronic product development. His current research is focused on technology platform development.