Knowledge reuse in industrial practice: evaluation from implementing engineering checksheets in industry

Abstract

In multi-domain product development organizations, there is a continuous need to transfer captured knowledge between engineers to enable better design decisions in the future. The objective of this paper is to evaluate how engineering knowledge can be captured, disseminated and (re)used by applying a knowledge reuse tool entitled Engineering Checksheet (ECS). The tool was introduced in 2012 and this evaluation has been performed over the 2017–2018 period. This case study focused on codified knowledge in incremental product development with a high reuse potential both in and over time. The evaluation draws conclusions from the perspectives of the knowledge workers (the engineers), knowledge owners and knowledge managers. The study concludes that the ECS has been found to be valuable in enabling a timely understanding of technological concepts related to low level engineering tasks in the product development process. Hence, this enables knowledge flow and, in particular, reuse among inexperienced engineers, as well as providing quick and accurate quality control for experienced engineers. The findings regarding knowledge ownership and management relate to the need for clearly defining a knowledge owner structure in which communities of practice take responsibility for empowering engineers to use ECS and as knowledge evolves managing updates to the ECS.

1 Introduction and motivation

Knowledge is regularly seen as a valuable asset in modern product development as most products are developed in generations and as new product generations are based on existing products (Grant 1996; Alavi & Leidner 2001; Albers, Bursac & Wintergerst 2015). Existing products, such as precursor products or products of competitors, are called reference products (Albers et al. 2015). The new product or its sub-systems are either adapted to new product generation by means of carryover or are newly developed based on shape or principal variation. This situation needs to be considered when uncovering development methods and processes to make existing knowledge reusable to achieve increased efficiency. The product development process of new product generation is subject to knowledge gaps and engineers are continuously directed to close these gaps to minimize the risk while satisfying customer needs. According to Albers et al. (2017), the success and competitiveness of an organization will increasingly depend on how quickly it can absorb knowledge and thus expand, disseminate and bring organizational knowledge to use through actions and decisions based on the closure of knowledge gaps. The terms and relationship between knowledge and information are heavily discussed by others and in this paper knowledge represents the understanding of situations and their context, insights into the relationships within a system, the ability to identify leverage points and weaknesses and understand the future implications of actions and decision taken to resolve problems. Information is seen as structured data with some given level of context and meaning, noting that both context and meaning require, human interpretation and understanding. Knowledge is thus an extension of knowledge providing the ability to take proper action and decisions based on true belief (Alavi & Leidner 2001).

In the field of systems engineering design, aspects like multiple stakeholders, various documentation and rotation roles in the design process make effective reuse of codified knowledge complex. A main challenge from an organizational perspective is to create an infrastructure that leads to effective organizational learning by combining knowledge reuse methods (Argote 2013). Heisig (2009) compared 160 Knowledge Management (KM) frameworks and identified four categories of a successful infrastructure of which one of them was information technology (systems and methods) together with human-oriented factors (culture and people), organizational aspects (structures, roles, responsibilities, processes and governance) and management processes (leadership, strategy, goals, measurement and control).

Even though there is a high focus on knowledge reuse within the existing KM literature, i.e. project teams are repeating mistakes and reinventing solutions known in other parts of the organization. As part of managing organizational knowledge, it is widely acknowledged that the acquisition and provision of information are crucial and inevitable features of the modern workplace (Cross & Sproull 2004), which is particularly true in engineering, a field where the majority of work can be classified as activities relating to capturing, disseminating or (re)using information and knowledge (King 2009). A recent study by Robinson (2010) investigated 78 engineers and found that they spent more than 55% of their time performing the aforementioned activities. Whereas engineers naturally reuse knowledge from personal experience, knowledge from other sources or entities within an organization often requires more effort and thus becomes a challenge, even if lessons learned from others and from former projects bring the possibility of increased project performance.

Knowledge reuse can be accomplished by either a personalization or a codification approach. The codification strategy is based on the document-to-person approach, in which people retrieve codified knowledge from knowledge management systems, databases, books, data warehouses, decision support systems and enterprise resource planning systems (Hansen, Nohria & Tierney 1999). The personalization strategy is instead based on person-to-person learning, in which knowledge is shared with other people (employees) through face-to-face communications, including on-the-job learning, storytelling, training activities and communities of practice (COP) (Brown & Duguid 2001). Especially in knowledge-intensive tasks, people prefer to contact their colleagues directly when in need of assistance even if support can be acquired from a codified format (Julian 2008; Petter & Randolph 2009). However, a personalization approach comes with several challenges regarding standardizing best practices and its possibility of transferring knowledge with a time distance (over time) (Corin Stig 2015).

Knowledge reuse requires some form of knowledge transfer. However, although in knowledge transfer both insufficient and excessive levels of (predominantly codified) knowledge are associated with performance decline, empirical evidence suggests that moderate levels lead to effective performance in engineering teams (Patrashkova-Volzdoska et al. 2003). Essentially, attempting to transfer too much knowledge leads to information overload, so that an individual’s processing capabilities are exceeded by the processing demands of the knowledge received (Allen & Wilson 2003; Eppler & Mengis 2004). Such overload, especially codified knowledge such as technical reports, has long been recognized as a problem for organizations and is increasingly so in today’s highly intense knowledge work (Edmunds & Morris 2000).

Altogether, the research on knowledge reuse illustrates the need to evaluate approaches for capturing and disseminating engineering expertise, and how to foster improved knowledge reuse in product development. Engineering Checksheets (ECSs) were implemented at the case company to overcome some of the known challenges by exploring a concrete and structured format in order to be more lightweight regarding capture and disseminating knowledge, especially focusing on supporting knowledge reuse on the engineering level. Further, such efforts need to find a good balance between personalization and codification, fostering prosperous and valuable human-to-human contact, maintaining knowledge over time, decreasing the risk of information overload and together generating a healthy knowledge flow. The main aspect of the ECS is to divide and structure the knowledge into items that are more easily acquired by the individual who should apply it by focusing on thin slices of ‘know what’, ‘know how’, and ‘know why’, in order to more rapidly achieve the positive effects of knowledge reuse in product development projects. Further, the tool aim is to encourage knowledge reuse by combining checklists and guidelines in a light weight format that is easy to read, learn, apply and eventually update as core corporate knowledge is expanded. It is not aimed toward replacing existing knowledge documentation but giving a brief summary (with references to existing documentation) presented in a condensed easily reused checklist format.

1.1 Purpose of the paper

In this paper, we evaluate the implementation of ECS within a selected case company, that was introduced to the tool in 2012. The tool was introduced and supported by a spreadsheet and managed in a web-based document management tool. The use of ECS has been continuously spread throughout the organization and is actively used within its major parts. We now aim to evaluate the implementation and highlight benefits and remaining challenges primarily from the perspective of the engineers.

One of the steps in the process of evaluating the implementation was to explore which factors need to be considered in order to succeed with a support system for the reuse of experience-based knowledge in the design process. The outcome resulted in 14 evaluation factors mapped to the KM cycle, in which the KM cycle reflects the flow of knowledge. We later on used these evaluation factors to interrelate with the implementation of ECS across several departments.

The paper presents the intended support, a theoretical description of ECS, and compares it with the actual support realized, resulting from the implementation, in order to analyze and conclude with generic statements. This paper aims to bring clarification regarding the effects of the implemented system and related findings.

1.2 Outline of the paper

Section 2 presents the background including earlier KM research, evaluation factors used in this study and ECS. The research methodology is presented in Section 3 and the case study involving the industrial application is presented in Section 4. Results of the applied system in the organization are presented in Section 5. An analysis of the findings is presented in Section 6, is discussed in Section 7 and the paper closes with conclusions and a further work agenda in Section 8.

2 Background

KM can be seen as the process during which the organizational knowledge is managed over time to create value through reuse whenever needed. In this process, it is notable to remember that codified knowledge only provides value from codification efforts when (re)used.

Though it is easy to mainly focus on technology as the answer to more efficient knowledge reuse, the transformation to improved knowledge work often needs to involve both organizational and people domains to be successful. Most studies investigating knowledge reuse and codification put emphasis on KM systems, driven by the goal to make knowledge available to team members through the systematic storage of knowledge, and assuming it is correctly performed, the knowledge will be automatically reused (Alavi & Leidner 2001; Markus 2001; Watson & Hewett 2006). However, this does not seem to be true and points out the need to focus on a more balanced approach between personalization and codification while highlighting the reuse capabilities (Schacht & Maedche 2016). In order to enable effective knowledge reuse, companies should therefore follow a hybrid model composed of (1) codifying the KM structure (e.g. repositories) for knowledge storage and transfer, and (2) personalizing the KM structure (e.g. social network systems) for knowledge creation and reuse (Hansen et al. 1999; Desouza & Evaristo 2003). To support knowledge sharing through personalization, organizations typically gather in groups of knowledge specializations or COP. Further, Majchrzak, Neece & Cooper (2001) argue that human-to-human contact is made more efficient by facilitating a KM system that provides a knowledge base of initial information about the applicability, flexibility and quality of various solutions. Whereas a large amount of new technology has entered the market, most of them mainly consider the process phases of knowledge refinement and dissemination (e.g. databases, wikis, blogs, etc.) and according to Schacht & Maedche (2016), IT systems play only a little or even no role for creating new knowledge or improving knowledge reuse. Because many KM systems focus on the storage and dissemination of documented knowledge, they do not live up to their purpose as KM systems. Rather they are pure storage bins that are used only sporadically in practice.

The objective of this study relates to the field of Knowledge Based Engineering (KBE) where multiple initiatives have been performed to improve the reuse of expert knowledge and design solutions through KBE systems to capture and store knowledge regarding products and processes from different domains. However, KBE objectives attempt to save time and reduce cost in product development by automating repetitive design tasks whereas ECS sets out to guide the knowledge worker in applying existing knowledge without automating the activity (Verhagen et al. 2012). There are several methodologies which have been developed and/or used for the design development and deployment of KBE systems, such as MOKA (Stokes & Consortium 2001), CommonKADS (Schreiber et al. 2000), and KNOMAD (Curran et al. 2010). MOKA provides two levels of knowledge representation relating to knowledge capture and represents expert design knowledge, the informal level based on the ICARE (Illustrations, Constraints, Activities, Rules and Entities) forms and formal level. While most methodologies have been addressing the issue of knowledge capture and structuring/formalizing, none of them has yet integrated the concepts of design intent and design rationale to facilitate better reuse (Cho et al. 2016). Although a lot of research has been performed on KBE over the past decades, there is still a need to develop systems that support designers with expert knowledge from different domains of the product life cycle (Christ et al. 2013). Current KBE systems fall short of integrating knowledge properly, i.e. the main focus of MOKA lies in the ‘capturing’ and ‘formalizing’ steps focusing on the capturing of engineering knowledge rather than reusing that knowledge (Verhagen et al. 2012).

2.1 Evaluation factors

In order to evaluate a sociotechnical system for knowledge reuse evaluation factors need first to be identified. The mission of the KM system is to create and support healthy knowledge flow in the organization which can be explained by a KM cycle, representing the learning process within organizations (McElroy 2000; Rowley 2001). Various KM cycles exist where differentiating features make up their perspective, focus and level of detail (Blessing & Wallace 2000; McElroy 2000; Rowley 2001). In this paper, the identification of evaluation factors is mapped to the various steps existing in a KM cycle inspired by Andersson’s (2011) Experience Lifecycle. The KM cycle decomposes a multifaceted knowledge reuse process in order to identify and model the activities typically involved in knowledge reuse along with a focus on the process from an engineering perspective followed by the identification of a knowledge gap; searching for knowledge assets based on the knowledge gap detected, obtaining and grasping potentially valuable knowledge and assessing and evaluating the utility and value of the knowledge. This process is followed by applying it by adapting the knowledge to fit the context, closing potential remaining gaps by creating new knowledge by extending or replacing existing knowledge, identifying potentially valuable knowledge for future use, accumulating the essential knowledge in the refinement process and, finally, making the knowledge available by establishing methods of transferring and sharing knowledge for increased accessibility and availability (Stenholm 2016). A brief description of the steps in the KM cycle is further provided.

Acquire – Knowledge acquisition means adding new knowledge, for the individual but not necessarily for the organization as a whole or external parties, new knowledge and involves searching (Menon & Pfeffer 2003), sourcing (King & Lekse 2006), recognizing and assimilating potentially valuable knowledge assets until they are understood. External acquisition, such as grafting (adding desired knowledge from outside in the form of an individual) (Huber 1991) and searching from external sources, are also part of the knowledge acquisition process.

Assess – The process of assessment involves both analyzing and assessing the knowledge assets based on a specific culture, organizational rules and evaluation criteria. Included in this process is also the decision to verify the validity and reliability of the knowledge assets. The analysis involves reviewing and extracting what appears to be valuable in the asset and abstracting it further to find potentially underlying knowledge. Understanding what is needed in order to adapt a knowledge asset in an efficient and correct way to a new problem may require deep expertise, which needs to be made available to development projects (Smith & Duffy 2001). Knowledge assets that explain the design rationale and history of previous designs help this recontextualization process (Busby 1999; Smith & Duffy 2001). The assessment in this process is meant to identify and extract patterns and relations, then evaluating the value of the asset as a feasible solution to the new problem or decision (Corin Stig et al. 2015).

Apply – This is the process during which the knowledge asset is being used. It is worth remembering that unless this phase is accomplished successfully, the potential value of all other KM efforts is discarded. Duffy, Duffy & MacCallum (1995) define ‘design by reuse’ as the process of designing something by applying previous knowledge, found either in the minds of experts or stored in objects such as documents, software and prototypes. The knowledge assets can be applied throughout an organization to solve problems, improve efficiency, promote innovative thinking and make decisions. Knowledge assets from various sources often need to be understood and applied in order to efficiently being able to discover remaining knowledge gaps.

Create – Knowledge creation involves learning to extend or replace existing knowledge and is triggered when there is a need for new knowledge and when applying acquired knowledge has not closed identified knowledge gaps. The knowledge that has been applied can be the foundation for creating new and extend existing knowledge. This goal can be accomplished with the support from other individuals, both inside and outside the organization (socialization), adding knowledge from different explicit knowledge sources to create new knowledge (combination) or for example learning by doing, which is using knowledge from different explicit sources to gain new tacit knowledge (internalization) (Nonaka 1994).

Identify – The vital decision point where one needs to identify and consider whether or not the new knowledge might be valuable for future users, and if so, continue into the refinement phase. There is little value in refining the knowledge with which every engineer is familiar. Most interest is on the knowledge that differentiates experts from novices: the specific knowledge and experience gained during a product development project (Blessing & Wallace 2000). It is also of interest to consider whether it would result in extensible knowledge, which is when the knowledge has value outside of the specific product for which it was developed (Radeka 2015).

Duffy et al. (1995) define the identification process as the first two of three parts of ‘designing for reuse’, identifying and extracting possibly reusable knowledge assets. Tacit, or implicit, knowledge must be explicated through methods such as network analyses or brainstorming sessions before moving on to the refinement process where it becomes codified and organized into an appropriate format. Based on this process, knowledge assets that are found valuable will proceed to the refinement process. During the identification process, it is critical that emphasis is put on the quality and relevance of the knowledge extracted. There are certain cases where new knowledge does not lead to actions in the refinement process such as:

1. (i) When the learning simply supports previous learning, or existing guidelines.

2. (ii) When the occurrence was ‘one-off’ and is unlikely to happen again.

3. (iii) When the lesson might not be a lesson, but rather an observation or comment.

Refine – The refinement process is where the knowledge that has been identified and deemed valuable becomes codified and/or encapsulated into assets (e.g. documents in electronic and print format and/or live demonstrations and observations of artifacts). The refinement process needs to include two opposing actions; an existing knowledge record can be either updated or replaced, or a completely new knowledge record can be composed of new knowledge (Blessing & Wallace 2000). Capturing knowledge generated during the creation phase after the event requires considerable additional effort and results in a retrospective account. Explicit knowledge needs to be formatted according to a set of criteria and then becomes ready to be disseminated within the organization.

Disseminate – This is the process when the knowledge asset becomes stored as an active component in organizational knowledge, such as knowledge repository. Beyond their intrinsic value, knowledge assets must be stored in a structured way that allow them to be efficiently acquired. Related common activities include metatagging, annotating, classifying, archiving, linking, optimizing for search and retrieval, in addition to creating templates. Dissemination includes both transfer and sharing; transfer means preparing for the availability and accessibility to a specified receiver, whereas sharing is for an arbitrary receiver. This process involves both internal and external dissemination and is important, as employees are seldom aware of its existence, particularly when new knowledge is being created and refined.

By assessing each step for knowledge reuse, several factors can be identified that are vital in order to obtain a valuable flow of knowledge. These evaluation factors are summarized in Table 1.

Table 1. Summary of the evaluation factors affecting success of knowledge management system based on the steps for knowledge reuse

2.2 Engineering checksheets

The ECS is developed with one leg in the theory, mainly to increase the positive outcome related to the evaluation factors, and the other leg in existing KM methods applied in industry, e.g. guidelines, standards, wikis and checklists. ECS differs from some KBE initiatives as its focus is not on automating design activities but rather on guiding engineers in applying ECS through the inclusion of a design intent and a design rationale.

The main objective of the ECS from the industrial perspective is to increase the overall return on time invested into KM. This means primarily that the ‘apply’ phase of the KM cycle focuses on ensuring that knowledge has an actual effect on the decision-making in a product development organization. The reason for focusing on the apply phase was not only rational from a return on investment perspective but also from a motivational perspective. The occurrence of knowledge application is likely to have a positive effect on the further motivation for capture and refinement as those individuals who capture can observe the value for themselves as well as for others.

The concept of a Checksheet is defined as:

A Checksheet is a tool that presents an extended checklist of condensed, actionable and experience-based pieces of knowledge the aim of which is to direct knowledge users toward decisions or actions relevant to a predefined context. The Checksheet traces its origins to the checklist-based Know-what and is often complemented by guidance using one or several alternative Know-how’s for performing the specific action, along with the Know-why rationale under which circumstances the actions become relevant.

Figure 1. Presenting ECSs as a thin slice of knowledge.

By focusing on decisions, actions and considerations known from previous work, the ECS aims to provide predictability in terms of scoping, planning and executing the engineering work because it reveals how much of a challenge different concepts, technologies, suppliers or processes for testing or manufacturing have been in the past. The ECS is best described as a ‘virtual advisor’ which, beside predictability, also provides the knowledge user with guidance on how to either gather or disseminate information by providing links and references to relevant standards, design data, contact persons, templates and so on.

2.3 The engineering checksheet structure

Yuan Fu et al. (2006) argue that in order to improve team performance, it is essential to support know-what, know-who, know-why and know-how for collaborative decision-making. The ECS structure enables each thin slice or knowledge element (KE) to be described in three dimensions and based on work by Alavi & Leidner (2001) and Lundvall & Johnson (1994): Know-what, Know-why and Know-how to foster knowledge reuse and continuous improvement (Figure 1 and Table 2). Another relevant type of knowledge, Know-when is captured by connecting the KE to a timing aspect, such as a time plan, process phase, process step or milestone/gate. Additionally, Know-who is not formalized through the structure because the ECS relates to a domain and depending on how different work packages in the domain is organized and planned, an ECS may correspond to one or several organizational roles and KEs may fall under different individuals in a particular project or process.

Thin slicing the ECS has been inspired from the usage of the term in psychology to describe the ability to find patterns in events based on only ‘thin slices’ of experience (Ambady & Rosenthal 1992). The term means making very quick inferences with minimal amounts of information about the state, characteristics or details of an individual or situation. Brief judgments based on thin slicing are similar to those judgments based on much more information. Interpreted in this context, all available knowledge is not necessary for an engineer in order to guide him/her to better decision-making but that even small slices might be enough. Together with today’s increasing risk of information overload, the challenge to identify what critical parts of the available knowledge that should be presented is increasing in the engineering quest to make faster and more reliable design decisions (Robinson 2010).

To assist in the decision-making or action resulting from executing the KE, each KE is encouraged to include text, symbols, images, illustrations, trade-off curves and references to other documents, artifacts or people, as depicted in Figure 2. Each KE strives to be both condensed and visual and to use links to references when more information is needed and is captured somewhere else. Furthermore, the KE needs to strive for quality rather than quantity as it may be confusing and difficult to quickly assess overly extensive descriptions. If a KE would require the understanding of more fundamental and extensive knowledge either for the Know-why or the Know-how, such fundamental knowledge should be captured in its entirety in a more appropriate format and referenced by the KE.

Table 2. Structural description of a knowledge element

3 Research methodology

We perform the evaluation of ECS applicability and usability by applying the proposed Initial Descriptive II procedure in the Design Research Methodology (Blessing & Chakrabarti 2009) and through strong collaboration with a large industrial company which has been applying ECS during more than five years within various groups. The aim of the chosen methodology is to provide a generic statement about the partial implementation which makes it preferable compared to Action Research (Blessing & Chakrabarti 2009).

The topic of actionable thin-sliced knowledge items in an engineering context called for a deeper understanding of the real-life context of engineers in order to explore the applicability, usability and usefulness of the support, as well as issues, factors and links that need further detailed evaluation. The setup of the research project as a partnership with the case company gave access to detailed inquiry about the topic in a real setting. This access to data was the main rationale for selecting the single-company design, i.e. an opportunity to study a situation otherwise inaccessible to researchers, which Yin (2013) refers to as a ‘revelatory case’, along with the history of a lengthy research partnership providing the benefits of a ‘longitudinal case’. However, within the organization multiple product development departments were involved along with a department in manufacturing.

Our specific KM initiative was initiated in 2012 and throughout the research project, data were collected from the case company using semi-structured interviews, document analyses, informal meetings and internal seminars, along with long-term observations performed by one of the researchers. The study culminated in 21 interviews performed in early 2018 focusing primarily on ECS even if more general KM-related questions were included and conducted primarily with product developers, production developers, product managers and knowledge managers. Interviews lasted from 0.4 hours to 2.5 hours.

Questions regarding what needs the ECS is set out to fulfill, effects on capture and reuse, the process for using the method and the usefulness of thin slicing were formulized as open-ended questions and were followed up by questions based on the researchers’ former experience in the case depending on the direction of the answer. Analyses were based on audio recordings from interviews and the coding of statements in the interview transcripts. Further, the interview data were noted and organized by each protocol question and the identification of patterns and their relation to the research studied. The interview transcripts were communicated and approved by each participant. The analysis was presented during a workshop with outside researchers and representatives from the case company.

Reviews of existing literature were conducted primarily from the academic fields of Engineering Design, Knowledge Management and Organizational Learning.

The research question that guided this process was:

What effects can be seen by implementing actionable thin-sliced knowledge items in product development to foster knowledge reuse?

The ECS evaluation was guided by the factors summarized toward the end of Section 1.2. The factors were identified by the researchers by analyzing the literature on factors related to obtaining a knowledge flow within the KM cycle. An important aspect is the lack of a factor related to the absolute volume of knowledge contained. As the purpose of the ECS was to closely align with the KM cycle, it also meant that the focus was on the flow of knowledge rather than its volume. Therefore, the intention was not to capture and manage all existing knowledge. Instead, the aim of the ECS is to guide the engineer toward decisions and tradeoffs known from previous work in a predefined context so that engineers can be aware of what awaits them in the engineering process depending on targets and scope.

There are limitations to this study as the main aim is to evaluate the ECS method from the engineering perspective and in an engineering environment. Following a continuous introduction process spanning five years, the KM system did not include any custom software but only utilized already existing software. This led to the use of a spreadsheet IT system as the main carrier of knowledge for implementing the ECS. Also, the organizational and people effects have been outside the scope of the research project as these parameters have been too difficult to monitor and influence from the standpoint of external researchers. For example, associated training activities and structuring the roles regarding knowledge work in a company (e.g. knowledge owner and COP) have to a large extent been outside the control of the researchers.

4 Industrial application

This paper presents an in-depth, longitudinal implementation of ECS to increase the flow of knowledge in order to increase value to the organization and its customers. The organization involved in this study is a global B2B automotive Original Equipment Manufacturer, with the site primarily studied located in Sweden.

KM initiatives have different purpose and focus, whereas the main focus of this organization has been to reduce lead time in product development. Based on this, the goal of the ECS tool was to improve the quality of decisions made during a development task in order to:

‘Achieve effective knowledge application, with zero rework – avoiding predictable problems.’

The ECS method and IT system through which it is implemented is of primary focus in an evaluation while touching on aspects regarding its effect on an organization, processes and people. The potential and actual value of KM is not without measurement difficulties and this study sets out to collect qualitative data to evaluate the actual support of ECS with respect to the support intended.

The case study initially utilized researchers and master thesis students for the implementation of the ECS before a management decision to implement the method widely caused a gain of momentum by virtue of appointed internal resources for wider implementation. As of 2018, over 90 ECSs have been created for components, systems, processes and methods. The project has grown both in terms of the number of employees introduced and trained in the tool and the number of processes, systems and components for using the method for which the knowledge has been captured using the method.

A brief analysis of 25 ECSs shows that the average amount of KEs is 35, ranging from 16 to 61 with a median of 31. 26% of the KE includes one or multiple illustrations, whereas 21% includes references to either a person or another document. Table 3 illustrates a hypothetical example of a KE for a component within the requirement specification stage.

The majority of ECSs are created for knowledge areas that can be labeled as relating to components (e.g. headlamp, heating–ventilation–air conditioning unit, clutch-servo) or sub-systems (e.g. cooling system, instrument panel) and a few relate to technologies (e.g. ethernet communication), as well as complete-product features (e.g. load capacity). For each knowledge area, they cover the scope of engineering knowledge related to complete development, including knowledge of what to focus on, why and how with respect to defining requirements, developing concepts and detailed designs. A separate chapter of each ECS is also dedicated to knowledge of what to focus on and why and selecting verification and validation methods and technologies, executing these activities and interpreting the results.

Table 3. Illustrative example of a KE

4.1 Technology domain aspects for implementing engineering checksheets

As a previously mentioned delimitation of the study, a commercial and file-based spreadsheet tool was used both for prototypes and the final IT system for implementing ECS.

The template was divided into three separate sheets; the first sheet includes the main content of the ECS (illustrated in Figure 2), whereas the second and third sheets include instructions regarding the method and how to identify and input the content.

Figure 2. ECS Structure implemented through the use of spreadsheet.

The basic structure consists of four main sections which largely correspond to the main phases of the design process, as illustrated by Figure 2. Each KE is a single row containing five elements, Know-what (activity/decision/concern/issue) that the intended knowledge worker is advised to keep in mind or focus on, the Know-why containing the rationale as to why that is important, and the Know-how containing the advice concerning the method or approach for performing the activity, making the decision or considering the concern/issue. Furthermore, there are two additional columns, one for a potential illustration and another for further reference if the knowledge would be supported by additional knowledge (e.g. a design standard or method guideline) or information (e.g. a quality case report that justifies a particular advice in the KE). In addition, there are two more columns which are supposed to support traction in knowledge application, the Y/N/NA column where the knowledge user can indicate which knowledge is applied in the current project or design and a comment that captures thoughts and ideas which take place during the knowledge application to either explain how the knowledge has been applied or suggestions back to the knowledge manager for further refinement of the knowledge.

To guide the creation of ECS the second sheet of the spreadsheet was created using the ECS format in which each step of the instruction was formatted as KEs. The following background regarding the target and purpose of the ECS was provided:

‘The purpose of this checksheet is to help you capture relevant knowledge that is actionable (i.e. easy to reuse) for your component or sub-system. This checksheet is structured into the categories illustrated below under the heading “Design process in practice”. These categories have been identified during a study of how engineers reuse knowledge. For each category, there is certain knowledge to be reused. This knowledge can be captured by answering questions stated inside the checksheet on the second sheet. By answering these questions, you will capture your own (and your colleagues’ knowledge) and make a checksheet for your own component or sub-system that states the important Know-what, Know-why and Know-how connected to the categories listed below. In the third sheet, some examples are given for most categories to give a sense of the type of knowledge that goes into them.’

5 Results

This chapter presents the results according to the different knowledge roles that participated in the interviews, including the participants involved in and affected by the implementation of ECS. The roles are divided into knowledge manager, knowledge owner and knowledge worker who all contributed to increasing the efficiency of product development initiatives by viewing knowledge as a valuable asset.

First, we investigated how interviewees viewed KM and the motivation factors behind implementing a KM system. Aligning larger initiatives such as KM needs a shared view in order to succeed. During the early part of the interviews, the participants were asked to elaborate on the topic of KM and knowledge reuse. The answers mostly overlapped and can be summarized as ‘KM is a way of promoting certain knowledge or a way of working that makes it easier for engineers and that minimizes the risk in a project’. ‘Best practices are equivalent to standards for how to design at the moment’ and ‘standard is state-of-the-art and when you deviate from the standard you should ask for permission’ create a good perspective on the rationale for KM.

Various scholars have published research on the motivation factors behind successful KM and one interviewee stressed that it is important to define why and when ECS is necessary and what it is supposed to support and achieve. Incentives need to exist, even if they are often unclear, and must be properly communicated in order to provide a good and advantageous start.

‘KM is often seen as a boring task – you know something and then you are forced to put it into a document but don’t understand that the knowledge can build better products inside the company if the knowledge would be properly utilized’.

5.1 Knowledge manager

Knowledge managers are responsible to implement, support and assist in various KM initiatives regarding methods, processes and education in organizations. From a knowledge manager perspective, it is valuable to set up a system that aligns with the overall KM strategy and governance inside the organization. At the case company, the general product development process includes the necessary procedures to follow, as well as recommendations. For each gate, there exists a checklist that explains what actions that need to be implemented. One interviewee who uses the ECS stressed that the checklist states that ‘some KM tool’ should be used without specifying the ECS even if he argued that it could be very valuable.

The knowledge managers inside departments ensure that support exists for knowledge to be captured and fed into the KM cycle, thus becoming available in the organization by hopefully a pull effect created by the engineers supposed to benefit from reusing the knowledge. However, to succeed in pulling from the organizational knowledge, an awareness of its existence is presumed. When production shared their ECSs supposed to be used in design they were unsure if the ECS was used at all due to low awareness. They expected feedback on ECS content and imagined their way of working with KM to be updated, including frequently creating new ECSs and revising existing ECSs. They asked themselves how well their ECS was actually promoted by the design department because when they randomly asked designers, they did not recall seeing the ECS. Further, they stressed that even if they added a lot of effort to create the ECS, it seemed to be a waste of time from the reuse perspective.

‘I don’t believe that the designers do not want to use the ECS, it is more that they don’t know that it exists. So, it is more of a management issue…I believe that it is the functional managers’ responsibility to inform that the knowledge exists’.

COPs existed within different knowledge areas and were mentioned as valuable formats for sharing niche knowledge with other relevant practitioners, especially in large organizations where people are often dispersed. Thus, COPs are a valuable method to keep knowledge alive between projects and over time while increasing awareness of existing knowledge. COPs also worked as ways of increasing the awareness of codified knowledge in the organization by sharing references between cooperating individuals.

5.2 Knowledge owner

Knowledge owners are individuals who are primarily responsible for making sure that knowledge is captured and shared inside the organization. In the case company, there are regularly two types of knowledge owners for each knowledge area, one who is mainly responsible on a global level and one or several on the local level. On the local level, individuals are mainly assigned as responsible for a specific project in which they are involved and are thus responsible for reporting to the globally responsible knowledge owner. Knowledge owners are mandated to decide on what type of available KM support they want to exercise for fulfilling the objective of the organization.

Initiating the implementation of ECS in different groups was often attributable to orders from managers or to some special circumstance that stressed the need to capture the knowledge, e.g. retirement. In the initiation of implementing ECS, knowledge owners were given KM training both on the general level and for the overall understanding of the ECS structure.

Regarding the type of knowledge that can typically be found in the ECS, the answer includes everything from general guidelines to references to specific documents or roles/individuals depending on what the experts or team highlight as the most important based on their experience in a particular domain. During each project closure, the teams perform a Post Project Review; however, in comparison to ECS, the captured learning was described to not commonly capture detailed technology knowledge that is valuable for designing e.g. a specific component but rather process or integration-related knowledge. One knowledge owner responsible for two components stressed that the value of the captured knowledge in the ECS consisted of over 30 years of work and collectively more than 92 years of experience in one place.

‘Before we used ECS, this knowledge lived in the peoples’ mind. Documentation was mainly in the form of white books (corresponding to Post Project Reviews), which is performed after each project. But these books are not as precise or detailed on specific components as ECS, but they are written on a higher level and are often related to the process.’

Within the ECS, the KEs were aligned to timelines/phases to support the application process and align with the overall product development process. The timeline was mentioned as innovative and valuable, even from one knowledge owner who has abandoned ECS. Some knowledge owners stressed the fact that it ‘is important that the ECS not become a new checklist (monitoring list) that needs to be followed, but rather as something that supports design’.

5.3 Knowledge worker

Knowledge worker is not a formal role, but it involves everyone in the company who performs knowledge work and especially the individuals who capture, (re)use and update the ECS.

5.4 Capturing knowledge into ECS

Capturing knowledge is not performed easily and will always require effort from everyone involved even if the ECS has been developed to require a low level of explanation to get started. During interviews, the structure was mentioned and appreciated as valuable in guiding the capture of valuable content.

‘An OK way to document the knowledge regarding products and processes’, ‘the method is quite self-explanatory’, ‘The thin slices are good, but it took some time before we understood the different parts, know-what, know-how and know-why’, ‘It was useful even if I had prior experience of these kinds of components from more than 10 years. It has been quite good to put it on paper and review it and very useful for me when I start designing a new component’ and ‘I have worked for many years, but ECS has really helped me structure my knowledge in order to be able to check whether everything has been considered’.

One issue was elaborated on during the interviews, i.e. searching for company-specific knowledge to include and finding the desired balance on the level of detail that should be captured in order for the knowledge to be easily understood but still condensed.

‘It is difficult to avoid redundancies, not including information that already exists somewhere else, and only add knowledge that we not have documented before’, ‘ECS holds a lot of information in relation to its size’, ‘ECS is definitely not a waste of time, always valuable to have a good database with specific knowledge, created by people who have been working with the component for many years’, ‘it is possible to google most of the knowledge needed, but the knowledge in the ECS is unique and easy to find’ including ‘links to presentations, legal requirement documents and guidelines. It is valuable to gather as much of the knowledge as possible into one document and then linking it to other documents in order to not duplicate the information. It is thus gathered in one single place’.

The creation process of the ECS was performed in an iterative and dynamic approach to which two main variants regarding responsibility of the draft process were noticed. First, when an individual was assigned the task and second when it was assigned to a group. This difference affects who will decide on what is important and thus what content that should be included. In both cases the iterative approach of drafting the ECS and set it into use as fast as possible was mentioned as helpful in order to understand what is important, why it is important and to clarify underlying reasons. Further, production argued that they realized their unique knowledge in the organization and that it could be helpful for others, including the designers.

In the department for Human–Machine Interface (HMI), a newly hired staff was assigned the responsibility to draft the initial ECS under the supervision of a supportive manager. The manager argued that assigning a less experienced individual probably led to more basic questions being asked and that if a more experienced person would ask the question, many of the necessary aspects would probably be seen as common knowledge and thus be neglected. Further, they also set up regular meetings with other people outside the department and asked them what questions they had regarding HMI. The purpose of this approach was based on the idea that the ECS would later on be spread to these departments in order to serve as a place to find the answers to some of their questions.

In the production department, they gathered a team from several production plants to force participants to come together and elaborate on known issues. Sometimes ‘the best practice’ differed between plants and forced participants to settle on what actually was the best practice and what knowledge to share with designers. The cross-functional along with cross-plant work also supported an equal and deeper understanding while communicating and creating visualizations of the knowledge.

‘In the beginning, we held idea discussions focusing on identifying areas where we today have known issues and where we thought we could make improvements by sharing our knowledge with the product development. From all ideas, we picked those that we believed were the most important related to production and which resulted in decreased costs for the company and increased quality. Production specialists then met the line operator in order to gather information about what particular issues they identified with the specific component. This was collected into one ECS that only regarded that specific component’ and ‘it is one thing to know that there are issues, but another to really understand why’.

However, the experience and outcome were not always positive and some knowledge workers performed the task of creating the ECS to fulfill the KPI without achieving the improved knowledge reuse.

‘I spend a lot of time creating the ECS, but finally I succeeded, stored it but never really opened it again. What a pity’ and ‘We haven’t seen any changes after the introduction of ECS because I only did it to make people happy and I got a green KPI and no one asked anything afterwards’.

A dynamic approach proposed to create the ECS is difficult to measure in time and most of the interviewees preferred not to guess, but some approximations were provided. An operator and a designer mentioned that the total time for creating an ECS was about 100 hours during a quarter within a group of five people while another designer mentioned 30 hours for an ECS containing 10 KEs. They believed that this would save time in the long run because they now use the ECS as support in spreading knowledge about previous obstacles that have been identified and in that way decreasing the risk of repeating them. However, no further formal cost-benefit analysis has been performed in the study. It is worth noticing that time was mentioned as one of the barriers for creating ECS.

‘What hinders us from creating more ECSs is probably the time to create the initial draft. Is it worth creating it compared to the trial and error approach?’.

5.5 Acquiring and applying based on ECS

A knowledge worker is often supposed to reuse existing knowledge instead of creating new, thus stressing the need to be able to acquire existing codified knowledge. Research shows that it is beneficial to front-load knowledge which has been further supported and mentioned in interviews. Further, interviewees stated that front loading should be in focus at the start of a new project phase, as well as when a new employee is brought onboard. One interviewee responsible for more than 200 components argued that the ECS had been very valuable in order to support references regarding the most important aspects to consider, and even though she was very experienced, the time pressure had made her overlook some of them if not the ECS had been used. Even if the ECS might provide the highest value to new employees, it is mentioned to be valuable for skilled individuals to review it and making sure that everything has been covered.

‘When you have a new project, it [ECS] will be state-of-the-art of the relevant knowledge and then you will go through the list and pick up what you think is important. After you have done that, I’m not sure if picking up the ECS again will be a natural behavior. But new people are eager to learn and they will probably search for new knowledge, whereas other more experienced people will probably trust their own personal experience more’.

The balance between acquiring knowledge through the codification or personalization approach was frequently discussed by the interviewees. They also explained that before the introduction of ECS, the natural behavior was to give someone a call with specific questions, but this behavior has recently decreased. Further, it also differed between individuals and their personalities in that some preferred to have face-to-face interactions whereas others primarily used codified knowledge.

‘Documents are good, a necessity for KM, but coaching and communicating between people is also necessary’.

Several alternatives on how to apply the ECS were mentioned. One procedure was that an individual received the ECS and applied its content during design. During this process, the team gathered a couple of times to hold review sessions during which questions were asked in order to provide input and make sure that the knowledge was considered. Another interviewee explained that ‘going through the list [ECS] is boring’, but having a discussion around its content is a valuable complement to the process.

An engineer said that having several KEs with important aspects form a good start, but you might need someone who can further explain its content to minimize the risk of misunderstanding. Several interviewees argued that ECS is a good support system for new employees to speed up their process of getting onboard and achieving traction and being brought up to date with relevant knowledge extracted from key colleagues. Not only the specific component in focus but also interfacing components.

Interviewees proposed that new employees should first go through the ECS by themselves, followed by a walk-through with someone in charge of creating the ECS in order to provide a deeper understanding if needed. In this process, the structure of ECS is valuable as it supports a more practical possibility of going through the KEs one by one to make sure that the content and the following consequences of performed action or decision are understood.

‘Quite easy to explain as a valuable tool and a good way of making sure that nothing, that we know about, is missed by indicating the piece of knowledge with a checkmark’.

Interviewees indicated that if someone is unfamiliar with the component in focus, the ECS will most probably not be so detailed that it is fully self-explanatory as the ECS sets out to capture the essential company-specific knowledge about best practices and known pitfalls while neglecting basic aspects which can be found externally. The language in the ECS can sometimes be complicated with several company-specific abbreviations, which is mentioned during the interviews as being outside the scope of the ECS.

In the case company, there is currently an inconsistency in how to store the created ECSs and thus also how to share them. Several possibilities were mentioned, such as shared Teamplace, local computer and corporate Wikipedia. Depending on the option, only the latest version was stored, whereas in some cases several versions were kept. Where the ECS was stored did most of the time not become an issue when individuals were aware of its existence. However, it was explained that several times there was a time gap between the upcoming need and when they became aware of the ECS existence. In most cases, the awareness was raised through their managers.

Knowledge validity is naturally important and several aspects were mentioned that increased the trust of the knowledge workers in the captured knowledge, i.e. references to other documents, notes of who captured the knowledge and when it was captured.

The issue of how many hours a new employee saves by using ECS was challenging and one interviewee mentioned that a new employee probably saved 10 hours of direct dialog with the most knowledgeable engineer in the field thanks to the ECS, which then saved an equal amount for the expert. Another interviewee predicted that a new employee probably saved around 100 hours in total considering the support of finding the right documents, direct contact with others and avoiding mistakes.

5.6 Updating ECS

Keeping documented knowledge updated and removing old content is important to foster trust and maintain validity. The number of updates differ in frequency from a couple of times per year to never. The motive for updating also varied and some reasons mentioned were that technology changed, best practices improved and faults were identified.

Some teams went through the ECS together on a regular basis and identified lessons learned to be shared with and added to the ECS. They also held sessions where quality issues were summarized and if any valuable lessons were identified, they were added to the ECS. Teams working with components of high similarity were more eager to come together to share and update existing knowledge because they had more in common even when the team was dispersed.

‘My team is easier than many other teams because we work with the same components but different brands, but overall very similar questions. In the case when someone works on a side skirt, someone else on a panel, a third person on deflectors. This results in a team that is diverged which also makes their lessons learned diverge.’

It was mentioned that a couple of years ago, lessons learned were seldom discussed as something that should be captured except when formal lessons learned sessions were held. However, during the study an email thread was reviewed by the researchers which revealed a discussion during which an engineer identified new knowledge as valuable to capture and the discussion circulated around where and in what form it should be captured. In the end, it became one new KE in an ECS.

6 Analysis

The analysis of the ECS implementation in the case company is divided into three steps. First, the application itself with the surrounding process and method is evaluated and will answer the question if the support can be used and if it indeed addresses those factors it is supposed to address. Second, the success of ECS is evaluated with the aim of identifying whether or not the support has the expected impact. The third and final step concludes with the issues and factors that need detailed evaluation.

6.1 The ECS application

The implementation of ECS in the case company has been an ongoing process for several years. Most attempts to initiate the use of ECS as support in the design process have been successful, but a few attempts have failed due to various circumstances. An example is when the ECS was created to fulfill a defined KPI without individuals solely believing in the method. Another example is when the awareness of the ECS was not raised between the necessary departments.

Initially researchers and the master thesis students performed interviews and follow-up seminars regarding the very first ECS with the knowledge manager in combination with other important stakeholders, including other experts, component and process managers and engineers involved in the design of the product and process. During this process, it was found that using inexperienced engineers or master thesis students ensured that all basic questions were asked and dwelled upon with good enough input for the initial ECS draft. Once the draft had been made, it was easier for the knowledge worker to continue adding content to, it as well as explaining to other stakeholders the type of content and structure so that they could also provide content. From an implementation perspective, this was a positive aspect as the approach was scalable with the only bottleneck being the KM expert (in our case the researchers) who is needed to get the students going. This process is comparable to the way in which the HMI department used a newly hired individual for drafting their first ECS. A central idea during the implementation was to identify a responsible person, often an expert or senior engineer, who became the knowledge owner of an area. This individual often acted as the first and main source of knowledge. Deciding on a knowledge owner seen as trustworthy also increases the trust in the knowledge itself and according to Bao, Xu & Zhang (2016), trust in supervisors and peers serves as a precondition for knowledge sharing and might provide perceived safety of intra-firm knowledge transfer.

During the five years of implementation of the ECS in the case company, the growth has been steady from the first initial draft performed by the researchers to now incorporating more than 92 different knowledge areas, including components, processes and methods. The growth provides an indication of ECS success and can be connected to the method and process focus of the introduction, as well as the simultaneous organizational change process of introducing knowledge owners to the organization. As knowledge owners have requested an easy-to-use-and-share format for their core knowledge, ECS got a natural advocate within the organization. The traction of ECS inside the case company through both governance and organic growth indicates that ECS has been successful in the applied and tested environment. The growth along with several success cases observed during this study and described during interviews further supports the fact that ECS fulfills the goal of being a KM system that fosters healthy knowledge work and feeds the KM cycle with codified knowledge.

The email conversation between employees around newly gained knowledge and where it should best be captured showed some evidence that a healthy environment and culture regarding KM is prospering inside the company. It bears witness of a process where captured knowledge is improved and a new way of communicating about knowledge inside the organization has emerged where ECS facilitates a natural storage for new knowledge.

6.2 Usability & applicability

The usability of ECS can be examined regarding the IT system, structure of content and the content itself.

Regarding the IT system, the overall conclusion is that using spreadsheets comes with several positive aspects as well as some drawbacks. Using an IT system that already is in use provided a smooth initiating process compared to bringing a new IT system through the approval process of the IT department and out to users. All users were already well aware of the functionality of the spreadsheet system which made it possible to go directly to the structure of the ECS inside the spreadsheet. Compared to implementing a new system, even though it might be user friendly, would require additional time for the individuals to become familiar with its functionality. But drawbacks come with the overflow of functions that exist in the spreadsheet system compared to what is necessary to support ECS which becomes a risk to slow down efficiency. Other drawbacks noticed were the poor functionality for managing images, searching for its content without opening the document and version control of the content.

As a result of the basic idea to let each individual decide on where to store the ECS depending on his preferences, the degree of central steering became low due to multiple storage places. This became an issue for evaluating the implementation process. On the other hand, a document-based system made it possible to store in any traditional way whatever environment would be preferred, such as local computer, shared folder or common platform, i.e. Sharepoint and easily disseminated by email.

Knowledge workers supported the ECS structure as valuable, even if it was a minor challenge in the beginning to understand how to divide the knowledge into the KE structure with Know-what, Know-how and Know-why. The process of reusing the knowledge is more easily performed thanks to the structure compared to the more unstructured ways of capturing knowledge. Knowledge managers found it valuable in order to follow and achieve an overview of the progress.

Analysis of the usability of the content is the reason why more than half of the ECSs created are still in use and their content is frequently reviewed and used. Follow-up interviews were used to confirm the initially identified KEs and to trigger the identification of additional KEs. After verifying the initial ECS, the document was introduced to designers and validated by actual usage by designers, experts and managers with the idea that a frequently used knowledge base becomes more valid as it is regularly visited.

6.3 Usefulness and impact

Measuring the impact of improved KM represents one of the most challenging activities in KM research due to its context-specific and multi-dimensional nature (Chen & Huang 2009). On the other hand, several interviewees in groups where ECS was adopted witnessed an increased awareness of knowledge important to their daily work as well as capturing knowledge important for future use and reusing already existing knowledge.

The impact evaluation is analyzed based on the factors in the KM cycle along with the results from observations and interviews and is summarized in Table 4.

Table 4. Presents the main factors of the ECS implementation related to phases in the KM cycle

7 Discussion

To address the research question What effects can be seen from implementing actionable thin-sliced knowledge items in product development to foster knowledge reuse?, we identified several evaluation factors regarding the implementation of sociotechnical systems and followed the ongoing implementation of ECS during a period of five years. The implementation factors mainly evaluated the achievement of the method for creating a valuable flow of knowledge inside the organization and to foster long-term learning.

In the most prosperous cases of using ECS, the study found no instances where it was solely used as a codification approach without any elements of personalization which follows the Desouza & Evaristo (2003) and Hansen et al. (1999) proposed hybrid model. In line with Majchrzak et al. (2001), ECS has shown evidence of carrying initial knowledge about the design rationale for a component regarding its applicability, flexibility and quality of various aspects, thus becoming a valuable source and knowledge base to support extended discussions, for example the meeting with global knowledge owners where the ECS worked as the central document which was collaboratively revised and improved continuously by group members.

Within all organizations, there is a preexisting behavior which all KM initiatives need to consider. In this study, we implemented a codification approach to foster improved KM while still paying attention to the value that personalization aspects can bring to the initiative. In the process of finding the desired balance to analyze the way individuals behave when knowledge is searched for, we know that people prefer to contact their colleagues directly when in need of assistance (Julian 2008; Petter & Randolph 2009). In one instance, when an expert was reached for help, the expert sometimes replied with a link and explanation of where in the ECS the answer could be found. However, most of the time, the expert responded directly over the phone or by email and did not refer to where the answer could also be found. This is a signal of what might become a long-term issue where the codification initiative might be undermined unless the culture of behavior aligns with the KM initiative (Hansen et al. 1999).

Schacht & Maedche (2016) state that the IT system plays little or even no role for the improvement of knowledge reuse and the HMI department introduced ECS for their design process related to the electronic field. During a three-year period, two other systems were also offered to the department in order to support KM. When transferring between the systems, several aspects of the ECS were mirrored on a concept level, e.g. the Know-what, Know-how and Know-why, along with structuring the knowledge into KE, as well as keeping the timeline by aligning KE to different steps in the PD process. However, in their ECS initiation process, they used a spreadsheet template from a neighboring department including different categories which were never really valid for the HMI department and was thus disregarded when the IT system was upgraded.

The functional organizations that applied ECSs maintain, update and validate them as new knowledge arises based on new experience. Ideally, ECSs make up an accumulated knowledge base reflecting what a company has learned over time about good and bad design practices, performance requirements, and design interfaces that are critical to quality characteristics, manufacturing requirements, and standards that make up the design. ECS may define crucial steps within a process and/or provide guidelines for specific characteristics of a product design. They are based on firsthand experience and are updated and validated regularly to incorporate any new or technological developments. In all cases, these ECSs contain detailed information about the product or process. Furthermore, the same groups that use the ECS maintain and update them regularly at reflection events, often organized in combination with knowledge owners and the larger COP. Maintaining the ECS is never a corporate IT function, or the vague responsibility of ‘engineers’ in general.

7.1 Suggestions for improvement

Viewing the implementation from a more holistic viewpoint, the implementation can be seen as a success due to the expanded use through both governance implications and organic growth. However, the implementation of ECS lacked clear directions on how to store and disseminate the created ECSs and thus ended up to be very dispersed in the organization which complicated the analysis of its growth. Depending on the IT system for support in future implementation should be a critical aspect to improve the evaluation process.

Another issue that the researcher comes across during the study was that mainly the first users involved in the implementation of ECS were educated on the tool including background and preferred way of working, which was poorly transferred to second users and further complicated upcoming acceptance and adoption due to misunderstandings and lost awareness of existing ECSs.

8 Conclusion and further work

This paper evaluated the implementation of a new tool called Engineering Checksheets (ECS) for managing knowledge within an engineering company. The tool was introduced stepwise starting in 2012 and had at the point of our evaluation grown to incorporate about 100 knowledge areas. The perspective taken in the analysis of this evaluation has been from the engineering viewpoint, benefits and challenges with practical knowledge reuse experienced in daily engineering work, hence the ambition of this paper to expand literature beyond the traditional, management view on organizational learning and knowledge dissemination. The aim of ECS is to reuse knowledge by combining checklists and guidelines in a lightweight format that is easy to read, learn, apply and eventually update as core corporate knowledge is expanded. It is not aimed toward replacing existing knowledge documentation but to give a brief summary presented in a condensed and easily reused checklist format.

Positive effects identified through the evaluation are that various types of knowledge workers in a development setting experience support by the implemented tool in different ways. We have concluded that the Checksheet tool is particularly beneficial for inexperienced knowledge workers as compared to previous, ad hoc and dispersed practice when quality assuring a delivery, identifying the most critical design parameters and identifying critical inputs from others in the chain of development. These three features have not been systematically captured in the previous development methodology, e.g. lessons learned reports and detailed guidelines and are thus new to the company. In relation to the implementation process, and the perceived maturity of the Checksheet document, we can conclude that an early draft of the ECS is supportive and often ‘good enough’ for engineers to start working. A draft ECS further encourages the update process and contact with knowledge owners. Hence, the ECS should be put into practice as soon as possible, rather than waiting until engineers, or knowledge owners, feel that it is perfect, as this is unlikely to ever happen due to the continuous evolution of the corporate knowledge.

For experienced knowledge workers, the perceived gains are related to less stress as they use the ECS to make sure that necessary actions have been taken according to existing knowledge without necessarily relying on the mind. It is evident that ECSs in practice contain an average of 35 KEs, and even experienced engineers will eventually forget to check or implement a few of them. However, this necessitates the ECS to be agile toward experienced engineers as they seldom have the patience to go through long and tedious documentation, whereas experienced engineers often only need to glance on the ‘know-what’ and can thus finish an ECS in a few minutes.

During the extraction of knowledge into ECS, it was concluded that the format is not appropriate for either collecting all existing or all types of knowledge. Therefore, it is important to highlight the necessity of not duplicating detailed knowledge existing in other forums, but instead reference these sources. Multiple times in the evaluation of ECSs, it has been stated that to be kept relevant, minimalistic and up to date, knowledge needs to be systematically reviewed by everyone involved through a shared responsibility to report issues with a single knowledge owner being the main professional responsible for the complete content of the ECS.

Regarding knowledge owners and organizational structure, we conclude that there is a need to define responsibility for making sure that knowledge is captured in the project and shared globally, in both the COP, as well in the general documentation and specifically the ECS. In the study, some successful cases were highlighted where the knowledge in each domain was shared during regular meetings reviewing the ECS through the combination of local knowledge owners (responsible for the project) and a global knowledge owner connected through the COP. From the organization level, there is still a lack of formalized governance structure for managing the creation, maintenance and reuse of codified knowledge. This was to some extent managed by the knowledge owners and COP, but were not formalized as routines integrated in the general development process. When people (e.g. knowledge owners) are replaced, there is a lack of formalized support in transferring documentation and ownership. The same principle applies when resources in projects are replaced or added.

In the organizations, the balance between codification (in this context the ECS) or the personalization approach (represented by knowledge owners and the COP) was not explicitly discussed and some cases witnessed about potential issues. Even if the process of codifying the knowledge had been completed, the knowledge owner responded to a knowledge request from a colleague by spending time and verbally providing guidance in front of referring to the asset. However, if guidance beyond the captured knowledge would be necessary, the knowledge owner should be available to provide such guidance but first and foremost refer to existing codified assets. From the engineer’s perspective of applying existing knowledge, the personalization approach is perceived as easier and thus naturally becomes a threat to the codification approach unless that habit is changed.

From the knowledge manager’s perspective, we can conclude that much of the knowledge captured in the ECS was not codified before or existed in project-specific documents of lessons learned. The ECS has fulfilled the task of systematically carrying learning from past projects to new projects to be stored connected to engineering tasks in an available format. In the role of knowledge manager, the study has also highlighted the need for continuous education and management follow-up of the tool for making sure that new employees understand its objective and the basic demand it fulfills. In a few cases, the ECS had found its own pace to the extent that Checksheets were being created and filled out without managers or knowledge owner pushing the tool. Further, the study has shown that this experiment has been successful without focusing on a specific IT system since the tool survived changes and updates of IT support systems, such as the introduction of a new Wiki system for managing the detailed development guidelines.

Recommendations for future studies relate to the implementation of a dedicated or integrated support system as the current tool was implemented using a Spreadsheet (file) based demonstrator as the only viable way forward. Regarding the ECS methodology and connection to the development process, a prominent issue is the current practice of locking down access to the ECS templates and completed sheets. A future study should thus include how ECS can be supported regarding IT tools where different concepts could be evaluated including existing IT tools such as a web-based project portal, a web-based wiki system or a corporate Product Lifecycle Management system, as well as the restrictions, rights and needs of the rest of the organization to take part in the knowledge generated. Beyond the technical aspects, future research should investigate the change in culture regarding the balance between personalization and codification strategies and the behavior evoked by different scenarios while using ECS.