It takes between 15 and 20 years to achieve widespread implementation of recent technologies from research to practice. Guidelines have shown to be an adequate method for efficiently transferring technology into an industrial context, especially in software engineering. However, recommendations for writing guidelines are still fuzzy w.r.t. content and structure, i.e., existing approaches do not give comprehensive recommendations on how to write meaningful guidelines. In this paper, we propose recommendations for writing guidelines. These recommendations include a reference structure that supports the author in writing guidelines by providing guiding questions for each chapter of a guideline. The recommendations are based on requirements that were elicited from leading companies in different industry domains. It was initially evaluated in a prototypical guideline instantiation by one of our industry partners.
In software engineering, there is often a huge gap between research and practice. How to transfer technology from research into industrial practice is a well-known and widely recognized problem [RR85]. Redwine and Riddle [RR85] state that software technology1 transfer usually takes between 15 and 20 years to achieve widespread popularization. However, adopting a new technology provided by research might efficiently help to improve business processes, achieve progress, and master technological and economic challenges. Failed technology introduction plans might tempt managers and practitioners to misjudge the advantages and the potential of a given technology [Ni00]. Hence, an actually promising technology might be discarded due to inadequate transfer [Ni00]. 1 We adopt Pfleeger’s technology definition, including e.g. techniques, methods, or tools [Pf99]. Copyright © 2014 for the individual papers by the papers' authors. Copying permitted for private and academic purposes. This volume is published and copyrighted by its editors. There are many approaches towards conducting and facilitating technology transfer, such as training, demonstrations, and workshops. In this paper, the sole focus is on documented guidelines that additionally support technology transfer. As can be concluded from the literature, there are certain empirically evaluated guidelines that are found to be comprehensible and thus constituting a qualified means to support technology transfer (see, e.g. [Br14, VAD12]). According to Pfleeger [Pf99] and Pressman [Pr88], the design of such documents pertains to the actual transition or technology provision, which is only one phase in a technology transfer process. To the best of our knowledge, there are no comprehensive approaches that provide detailed instructions on how to write guidelines, apart from a few general considerations that do not relate to the specific structure, representation, and contents. We address this gap in the remainder of this paper by proposing fine-grained recommendations for writing guidelines.
We focus on providing recommendations for writing well-structured and comprehensible guidelines that address all relevant stakeholders and support technology transfer. Our work emanates from the SPES-XT project, with a heterogeneous environment of many companies from different domains. Moreover, there are many different methods, techniques, and tools that need to be considered and supported. These aspects required us to create universal recommendations for writing guidelines. First, we elicited requirements for guidelines from the literature and from industry. Based on these, we proposed a generic reference structure that guidelines should adhere to, enriched with guidance on how to fill the structure with content. These recommendations were evaluated by means of a prototypical realization and an industry survey.
In this paper, we adopt the notion of technology transfer proposed by Pfleeger, comprising any insertion of a new technology into an organization, regardless of whether or not existing technology is replaced [Pf99]. Introducing technology in an industrial context is always related to organizational change [Pr88], and can thus be considered an issue of change management, which raises management and planning issues (e.g., stakeholder resistance) [DL01]. Technology transfer should not only focus on the technology itself, but also on the related organizational, cultural, and political impacts [Pr88], which should be reflected in the recommendations as well as in the instantiated guidelines. The remainder of this paper is organized as follows: First, we present related work in Section 2, followed by an overview of our recommendations for writing guidelines, their creation, and some detailed examples (Section 3). Section 4 presents the current status of our evaluation. Finally, we draw conclusions and present future work in Section 5.
Related work in the areas of change management and technology transfer deals with general management aspects that need to be considered during the introduction of a technology, primarily contributing process models and best practices. For example, Doppler and Lauterburg [DL01] distinguish different phases of a change process and present some key success factors, which include e.g. clarifying goals in order to establish stakeholder awareness, trust, and commitment. Souder et al. [So90] studied a comprehensive set of best practices and relate these to process phases. As another example, Robinson's technology transfer framework [Ro91] highlights the cross-cutting nature of technology transfer in the technology lifecycle.
Some authors focus particularly on the introduction of software engineering technology. Pfleeger [Pf99] presents a sequential technology transfer process that describes artifacts as well as constraints and supporting mechanisms, whereas Pressman [Pr88] proposes an iterative model based on evaluating the introduction success. Nishiyama et al. [Ni00] incorporate such aspects as customization to the organizational needs (e.g. by tailoring processes) and pilot projects. Moreover, a central resource should provide all relevant information. Nikitina and Kajko-Mattsson [NK12] also consider pre- and post-transition phases, and assign important activities. Some of the key factors w.r.t. software technology transfer include thorough analysis of the goals, benefits, measures, costs, limitations, and risks, as well as of the application context of a given technology [Wa94]. Involving, educating, and supporting the stakeholders, as well as obtaining management support is also crucial for successful technology transfer [Wa94, NK12].
Notwithstanding the importance of written guidelines, Pressman [Pr88] stresses the point that voluminous standards do not encourage reading and are thus not appropriate for early transition phases. Hence, guidelines should slowly evolve into comprehensive standards that are proven and advanced in practice, and “sold” to both managers and practitioners [Pr88]. Abernethy et al. [Ab00] support this aspect by distinguishing two complementary guidebooks; one discusses administrative issues addressing the management, whereas the other one provides technical guidance for practitioners. Other generic recommendations for developing guidelines include assessing the benefit of each instruction and using a precise terminology [Pr88].
Specific guidelines designed to support the transfer of various software engineering technologies into practice are also considered as related work2. In the following, we give an overview of some reasonable guideline characteristics. Guideline documents can be structured w.r.t. phases involved in applying a certain technology, e.g., reflecting a product life cycle [HKS10], or artefact types and tasks [Br14]. For each activity, its input and output artifacts [Br14, Mo99] and the respective contribution to the major goals [Ag87] could be summarized. Some guidelines, e.g. [BMP95], explicitly define preliminary phases or activities that need to be considered before applying the technology (e.g., assigning roles and responsibilities). Another common property of several guideline documents is their tailored suitability for practical purposes, which manifests in many ways. For instance, in order to foster proper understanding, a guideline could exploit the advantages of a well-known documentation format that is familiar to practitioners, and use illustrating examples (see, e.g., [VAD12]). A technology’s application context can be characterized by listing some domain properties that indicate high potential for applying it [La08]. Several guidelines such as [HKS10, RB05] also emphasize the benefits, challenges, risks, hazards, or obstacles associated with technology transfer or application. To sum up the current state of the art, some theoretical approaches exist for structuring technology transfer and change processes. Some problems associated with these, as well 2 In this context, we do not differentiate between introduction and application of a technology. as recommendations in the form of best practices or key factors, are also commonly accepted. These concepts are reflected in the structure and content of specific guideline documents. It can be concluded from the related work that there are no comprehensive approaches that provide detailed instructions on how to write guidelines, apart from a few general considerations that do not relate to the specific structure and contents.
In this section, we present our approach to support the writing of guidelines for the introduction and application of a technology. First, we show how we elicited requirements for guideline documents. Based on these, we propose a guideline reference structure. This structure is enriched with questions that support writing a guideline.
The first step of our approach towards giving recommendations for writing guidelines comprises the elicitation of requirements that need to be satisfied by guidelines. We gathered these requirements from two complementary sources: (1) a literature investigation to analyze the current state of the art, and (2) a survey with project partners from industry to collect requirements that directly represent the needs faced by industry. Originally, the focus of our literature investigation was on concrete requirements and comprehensive recommendations for guideline design. However, we did not find any precise requirements for guidelines in the related work. Thus, we expanded the investigation in order to include existing guideline documents and some general information on technology introduction in practice (see Section 2). By analyzing the structure and content of existing guidelines, some general conclusions applying to any guideline document could be drawn. We extracted requirements for guidelines, such as structuring the document w.r.t. introduction phases and activities, or using examples to illustrate the concepts (see Section 2). General considerations regarding change processes or technology transition also constitute valuable sources for requirements, since guidelines aim at facilitating and supporting change processes. For instance, as goal orientation is relevant for any change process (see Section 2), the documentation of goals is considered a general requirement for guidelines. In addition to the literature investigation, we performed a survey with industry partners in the SPES-XT project to collect industry requirements. The involved companies are from different domains, i.e., avionics, automotive, and automation. We analyzed and consolidated the responses from Robert Bosch GmbH, Daimler AG, Siemens AG, Audi AG, and Cassidian. During the consolidation of both elicitation activities into a unified set of requirements, we recognized an overlap. Note that the requirements address different aspects of a guideline. For example, some requirements can be mapped directly to certain chapters3 in a guideline document, whereas others relate to the whole guideline. Each requirement is documented, including 3 With the term chapter, we identify sections in the reference structure, whereas sections refer exclusively to sections of this paper. its source, a detailed description, the rationale behind it, and the domains from which it originates. This allows for selecting a relevant subset of the requirements for adapting the generic recommendations and instantiating domain-specific guidelines. Dependencies and relations between requirements, e.g., positive contributions, are also documented. Furthermore, we identified some statements that rather indicate a certain solution for a requirement; we documented these separately in the form of realization suggestions (see Sections 3.2 and 3.3). An excerpt of the resulting set of unified requirements is shown in Table 1. This excerpt of requirements shows exemplary requirements from each domain that we focused on. In the subsequent sections, we show how these requirements are implemented in our recommendations.
Based on the requirements, we designed a reference structure that constitutes a first approach towards a template for guideline creation. Although all requirements should be addressed, not all of them are directly reflected in chapter headings. The generic reference structure of guidelines is mainly driven by two aspects: (1) the use case of the guideline and (2) the target audience of the guideline. We first need to clarify whether the desired guideline is used within a company or across several companies, because internal aspects are more specific and tailored to a company’s needs. In contrast, external guidelines might not mention specific contact persons or departments, and might stay on a more abstract level. In addition, the target audience is specified as a set of reader groups that are addressed by such guidelines. We identified the following groups: • Decision makers decide whether the proposed technology should be introduced in the company/department or not. Thus, relevant information for decision makers includes, e.g., benefits, risks, challenges, required effort, etc. • Coordinators are responsible for introducing a novel technology after a positive decision has been made by the decision makers. Relevant information for the coordinators includes, e.g., the required technical infrastructure, organizational context, etc. • End users are those employees who have to apply a new technology in the company.
Relevant information includes, e.g., required input artifacts, steps to be conducted, etc. The table of contents that constitutes the reference structure can be found in Table 2. Six different guideline chapters are shown with their respective sub-chapters, which are detailed afterwards. This chapter structure reflects the majority of the requirements. For instance, requirement R-2 is addressed by including a chapter that describes the purpose, i.e., the goals and benefits of the technology that is to be introduced. However, as mentioned in section 3.1, there are requirements that cannot be mapped to chapters; e.g., R16 (Table 1) relates to the distribution channels of the guidelines that implement the structure presented in Table 2. The first chapter following the generic preamble is the Introduction, which serves as the motivation for introducing a given technology. The classification subchapter is used to specify how the technology will be integrated into established software development practices, such as processes or life-cycle models. The next subchapter describes the problem addressed and motivates the introduction of the technology. This is followed by the new technology’s specific and verifiable goals (see R-2 in Table 1). This chapter only regards generic goals, whereas specific goals of certain steps or activities are addressed later in Chapter 4.2.
The idea of the Management chapter is to get support during the introduction and application of the new technology, which is considered as a key success factor extracted from the literature (see Section 2). To allow assessing a technology’s appropriateness in a certain domain, suitable and unsuitable application fields, or at least some characteristics of these, are mentioned. In addition, possible disadvantages, weaknesses, and risks need to be specified. Another subchapter includes information on the effort required for the introduction and application (c.f. R-5 in Table 1). Ideally, quantifiable values or metrics are given for the purpose of precise prediction. The last part, which is optional, provides knowledge and experience collected in (pilot) projects.
The chapter about the Technology context establishes the foundation for dealing with specific conditions regarding the introduction of the desired technology, and addresses requirement R-1 (see Table 1). We distinguish between organizational, process, technical, and social contexts. The organizational context involves roles and resources in an organization. Within the process context, processes and existing technologies are related to the new technology. Required tools and infrastructure are part of the technical context. The last subchapter deals with social and cultural aspects that may influence the introduction or application of a technology. All these conditions allow adapting the technology to a specific organizational context.
The Technology application chapter contains instructions and guidance for applying the described technology independent of specific phases or artifacts. The first subchapter contains preconditions, such as required organizational structures, tools, qualifications, or input artifacts. The next part includes the different phases or activities involved in applying the technology. We recommend first visualizing the flow of activities with inputs and outputs. Then each activity should be described in detail, including goals, inputs, outputs, roles, resources, performed steps, and potential risks. Thus, we propose a more fine-granular sub-structure, which is not shown in Table 2 due to space restrictions. The last two chapters, a Glossary defining all relevant terms, and literature References, are optional. Additionally, there are important cross-cutting aspects of our recommendations for writing guidelines. A major point is the description by means of illustrative examples, which support the reader in understanding the technology and its application.
To provide support for authoring the content of the specific guideline chapters, the different chapters and subchapters of the recommendations include questions to be answered by the guideline authors. The concept of guiding questions is borrowed from the fields of education and didactics. According to Traver, “a guiding question is the fundamental query that directs the search for understanding” [Tr98]. Here, these questions should enable the authors to properly design a guideline so that it will achieve its goal of successfully introducing a technology in practice. All the guiding questions try to deal with different aspects, such as required information, creating structures, making decisions, or effects. Nonetheless, they are neither mandatory nor complete, but should rather support a writer in focusing on the relevant content of the current section. However, the author of an instantiated guideline is free to add more details or any other information that is deemed necessary. We present the questions according to the relevance of a chapter for each reader with regard to the presented requirements.
The first example taken from Chapter 3.1 is relevant for coordinators and addresses requirement R-1. It aims at describing the relevant roles and resources within the organization that have an impact on the introduction and application. The first two questions are obvious questions that need to be answered. The third question is intended to give the end users a single contact point for information and questions. • Which organizational units have to be adapted? • Who is responsible for this adaptation? • Is there central coordination of the adaptations? • Which problems are addressed by the technology to be introduced? • What is the benefit of the technology to be introduced? • Which effects are expected (e.g., time or cost savings)? • Can the goal be divided into sub-goals? • How much effort is needed for introducing and applying a technology? • What kind of efforts is required (e.g., human resources, training, tools, etc.)? • What are the costs for developing or buying software tools? • How does the effort evolve over time during introduction and application? • What is the ratio between the transfer effort and potential savings? • What is the ratio between the introduction effort and the desired savings
according to other technologies? The second example, Chapter 1.3 (see Table 2), is relevant for the end users and should illustrate the aim of the new technology. The aim should be described on a high level and subsume the common and process-independent goals. The second question emphasizes the benefits that can be gained by introducing the technology. This may increase the users’ motivation and agreement to apply the technology (see Section 2). The third set of questions from Chapter 2.3 should provide detailed information on the effort needed to introduce and use the desired technology. This could be realized, e.g., by means of formulas or cost estimations. Six different questions are proposed to be answered when writing a guideline. The last question can only be answered if a new technology is to supersede an established and already utilized one.
Prior to the publication of the recommendations, a two-step evaluation was conducted to gain feedback on the quality (appropriateness, etc.) of the guideline recommendations. First, the initial recommendations were evaluated by means of a prototypical realization by an industry partner, covering an exemplary engineering method. The goal was to create a prototype guideline by complying with the reference structure and answering the questions given in the recommendations. The initial version of the prototype guideline was then discussed with the recommendation authors in a one-day workshop. This discussion resulted in some changes in the recommendations and in the prototype guideline. Within this preliminary evaluation, the following changes in the recommendations were made: we added a guideline preamble, different target audiences, example highlighting, and a connection to a development process and we changed the structure of Chapter 4.2. Second, a survey with the industry partners is in progress. The variables of this survey are mainly opposite pairs, such as consistent-inconsistent, complete-incomplete, concrete-abstract, appropriate-inappropriate, etc. In addition, we asked for superfluous, missing, ambiguous, or inconsistent aspects. We also investigated the appraisal of the recommendations among practitioners, regarding whether guidelines created with this recommendations would help introducing a new method. The resulting feedback should help us to further improve our recommendations in a revised version. Unfortunately, at the time this paper is being written, no feedback has been received yet.
In this paper, we presented our approach towards providing recommendations for writing and structuring guidelines for introducing a technology in an industrial context based on elicited requirements. These recommendations include the presented reference structure and complementary, supporting questions, which help a guideline author to determine the content of guideline chapters by providing guidance throughout the creation process. We initially evaluated our recommendations based on a prototypical guideline creation and on the corresponding feedback.
Our approach and the results contribute to the area of technology transfer. We address a research gap in this area, i.e., the lack of precise recommendations for designing and authoring guidelines. For this purpose, we take into account general concepts of change management and technology transfer as well as a collection of specific guideline properties. Our recommendations are also based on the needs of industry covered in the requirements and focuses on specific reader groups, which facilitates writing and makes it easier to comprehend the guidelines.
Gathering further feedback from the project partners based on their creation of guidelines will allow us to significantly improve our recommendations. Finally, we aim at providing a mature version to our project partners to allow them to systematically introduce a technology and to master the involved difficulties.
This work was conducted as part of the SPES XT_Core project funded by the German Ministry of Education and Research (grant number 01IS12005E). We would like to thank Silke Steinbach for her valuable comments and fruitful discussions on this paper.