Towards a Modern Learning Organization: Human-Centered Digitalization of Lessons Learned Management for Complex Systems Development Projects

Abstract

The importance of learning from experience is incontrovertible; however, little is studied regarding the digitalization of in- and inter-project lessons learned in modern organizational practices. As a critical part of organizational knowledge, lessons learned are known to help organizations adapt to the ever-changing world via the complex systems development projects they use to capitalize on and to develop their competitive advantage. In this paper, we introduce the concept of human-centered digitalization for this unique type of organizational knowledge and explain why this approach to managing lessons learned for complex systems development projects is necessary. Drawing from design thinking and systems thinking theories, we further outline the design principles for guiding actions and provide a case study of their implementation in automated systems projects for maritime industries.

1. Introduction

As the world becomes increasingly volatile, uncertain, complex and ambiguous (VUCA), organizations are driven to incorporate digital technologies in order to learn better from project experiences [1,2]. There has been a growing interest in systems design and project management research to study digitalization—referring to the integration of digital technologies to redesign working processes—to aid complex systems development projects [1,2,3,4]. However, improving learnings from and for complex systems development projects in the digital realm is underexplored. Unlike a simple and straightforward problem-solving system, a complex system consists of a great number of related but varied elements with intricate interconnections, and the project’s success depends on collaborative efforts from multi-disciplinary and multi-function groups in an organization [5]. Those project learnings are largely experienced-based and gained over time by individuals and collectively by the groups in an organization, which are often known as Lessons Learned (LL) [6]. It is well acknowledged that LL are sources for enlarging and securing the bases of organizational knowledge and, thus, lead to competitive advantages when managed properly [7,8,9]. Previous research posited a central issue for organizations in learning from projects; the issue comprises the “learning paradox” [10,11]. As projects are temporary in nature, the paradox lies between the suitability of creating LL and their sedimentation as the project ends or the participants disperse [10]. Our work seeks to advance the understanding of this paradox in the context of complex systems development projects, particularity with regard to imminent digitalization on how to effectively manage LL for those projects.

The rise of digitalization can hold the potential to boost more productivity, transparency, accessibility and innovation, while it also can affect human behavior and alters the ways people socialize and collaborate with each other at the workplace [1,2,3]. This creates one of biggest challenges for managers or designers: how can we ensure that the adoption of digital technologies does not compromise but satisfies the organization and people’s needs so that they both may better adapt to a VUCA world. Despite being studied in the field of project learning with respect to complex systems development [12,13,14,15,16], the extant literature has been elusive on how to theorize and practice digitalization in order to aid solving such a challenge. Henceforth, this leads to an imperative research question in our study: how should lessons learned (LL) be digitally managed in aiding complex systems development projects in an organization? The practical issues are the lack of guidance, in terms of a working approach, that managers or designers can rely on when translating and applying techniques to the real world. In light of the issues, a number of scholars stressed the necessity of keeping an integrative perspective of human behaviors and the social nature of project learning regardless of the organizational context of digitalization [11,16,17]. In response, we propose an adequate approach of “human-centered digitalization”, which speaks powerfully to this need.

In essence, human-centered digitalization is based on problem-solving approaches designed to enact digitalization into the service of humans during LL management for complex systems development projects. Through the research lens of systems design, we contribute to interdisciplinary research by outlining a theory-based yet pragmatic approach to tackling the research question. Systems thinking and design thinking theories are employed to synthesize the results into a set of design principles that bridges the gap from theory to practice. By means of a case study, we present how they can be implemented in a real-life example—automated systems projects for maritime industries. The case embarks on a journey into customization and digitalization towards desired solutions by the case’s organization. The findings of this study and future research opportunities are concluded and discussed at the end.

2. Theoretical Background

2.1. Lessons Learned Management in Complex Systems Development Projects

The importance of managing LL is supported by a knowledge-based view of organizations [18]. This theory asserts that LLs as organizational knowledge are critical assets that allow an organization to deliver competitive projects in terms of product and/or service systems, as they cannot be imitated easily [6,18]. In the practical applied field of research, LLs contain practical knowledge as the “know-how” for situated practices in achieving certain system goals, including issue identification, similar experience application, work estimation, decision making, negotiation and so on. LLs are commonplace and may arise during a complex systems development project that delivers an integrated system composed of many components or sub-systems that may interact with each other due to individual experiences relative to simpler disparate system generation, the collective knowledge for systems integration relative to an overall solution intent, and the recommendations for enhancing system performance [5,6]. Over time LLs are accumulated by individuals and collectively by groups and organizations. Those collective experiences are the sources of prescriptive, applied or actionable knowledge that guide forward-looking practices. Instead of a simple collection of relevant explicit elements (e.g., success or failure), the implicit part of LL (e.g., recommendations) should be captured and accessed for future complex systems development. Notwithstanding its importance, structuring and sharing the implicit part is a far more difficult undertaking compared to the explicit part [6,19].

Previous research pointed that there is great value for an organization to learn from projects using LL management [9,10,11,12]. It is known that managing LL in organizational memory can benefit complex systems development projects by reducing the loss of intellectual assets when participants leave the company or the project ends [5,10]. By firstly learning what has worked and has not, cost reduction and increased productivity can also be achieved. Nevertheless, most complex systems development projects are not repeatable, concrete or routine situations but are partially or largely novel with respect to situational details. The novel situations, on one hand, represent opportunities for creating LLs as they are the main reason why new complex systems development projects exist. Complex systems development projects are thus temporary yet unique endeavors conceived to create a complex system that is in line with the organization’s strategy [20]. On the other hand, the related unknowns in novel situations should be managed as risks. As an essential activity, risk management has been subjected to thorough studies in complex systems development projects [21]. Neef [22] claimed that risk management cannot be conducted without LL management. Only the organization that manages the LL effectively could outperform others in complex systems development projects.

Managing LL reflects organizational abilities in response to risks induced by the fundamental complexity of a project as many individuals and multi-organizational functions are involved in different phases. In view of the inherited uncertainties of a complex systems development project, Christensen and Keriner [23] divided risks into operational uncertainty and contextual uncertainty. Every project, in the form of a temporary organization, shares some types of operational features in which uncertainty resides. This operational uncertainty is controllable and is based on factors known to the project at start-up. During the course of complex systems development project, it may face turbulence in its surroundings, including the management, market and/or other stakeholders. Additionally, the longer the development lasts, the more turbulence arises. This may result in a situation where the end solution is evaluated to a different standard than it was originally designed to meet. Christensen and Keriner [23] argued that this contextual uncertainty is out of a project’s control and can only be regarded in retrospect. LLs can serve as key knowledge for potential risk identifications, evaluations and treatments in guiding prospective practices by learning from the past and the impact they may have on a project’s performance [24].

2.2. Managing Lessons Learned and Learning Organization in Digital Realm

While the move to digitalization has and is accelerating at a frenetic pace (e.g., new technologies, remote work especially due to COVID-19, etc.), it constantly shapes the operation environment and human experience at the workplace. The new waves of digital technologies (e.g., 5G, IoT and AI) make more data and knowledge available and they can be managed in a more digitalized operational environment in an organization. Specifically, a digital platform becomes a critical source to transform an organization’s infrastructure for managing the exchange of data and knowledge, which occur among the practitioners during a product and/or service system development project as well as with customers who interact with the platform [25]. Therefore, managing LL in those projects at the present moment most likely will operate on a digital platform that involves certain organizational context, people and technology [12,20].

Adopting digital technologies generally opens opportunities for an organization to appropriate the benefits of LL management via the further development of information systems. In modern organizational practices, information systems have been widely utilized to facilitate codifying, collecting, storing, integrating, searching and disseminating required knowledge, which is also known as Knowledge Management Systems (KMSs) [6]. The realization of a new KMS requires organizational capabilities to learn and design a set of related activities—new habits at workplace—with a common purpose and the links between explicitly shared technical devices [6]. The common goal is to make intended knowledge and the associated knowledge processing environment explicit so that they can be managed explicitly [26,27]. However, current KMS applications mainly focus on solving “what we know” concerning the “content” in an organization environment [6,28]. The other two aspects of “who knows” relating to people as a knowledge agent and “how to use (digital) technologies” for augmenting capabilities in managing organizational knowledge are largely ignored but are deemed as important in managing the known content. Hence, the forward-thinking objectives of KMS in aiding LL management should include managing LL as human-based assets, enhancing digitalized operating environments, creating repositories and improving access to LL [27,28].

Being able to enact digitalization for LL management is becoming a necessary skill for modern learning organizations. According to Garvin [29] (p. 78), “a learning organization is an organization skilled at creating, acquiring, and transferring knowledge, and at modifying its behavior to reflect new knowledge and insights”. Skills reflect the organizational agility in response to the fast-changing business landscape in the digital age. An organization’s agility largely depends on how well an organization’s learning system works, which consist of many individuals and groups that are held together by knowledge flow networks and are not dependent on whether people are aware of them or not [30,31]. The form of LL management is thus often viewed as definable and customized knowledge flows within an organization that can confront concrete operational situations. According to Liu and Lin [30] (p. 41), “a knowledge flow represents the flow of an individual’s or group members’ knowledge-needs and the referencing sequence of codified knowledge in conducting organizational tasks”. In the context of project learning, individuals gained LL from practical ways of knowing by performing the knowledge flows themselves and via interactions with other participants [32]. The project’s knowledge flow of LL then becomes part of the knowledge flow networks embedded in organizational repositories, norms and practices under a common digitalized environment (i.e., a digital platform). In practice, only a small percentage of organizations appear to follow the flow they adopted, and the majority of LLs performed are found to be unsatisfactory [9,33,34]. It is thus imperative to obtain satisfactory (social) participation and (user) experience of which the inherent value of a digital platform is based on.

2.3. “What We Know and Don’t Know” in Digitalizing Lessons Learned Management for Projects

Managing LL involves complex social-technological processes, whereby the problem that people and organization may have is hard to define and address by digitalization [10,35]. Many researchers attempted to conceptualize LL management from various social-technical perspectives. Hartmann and Dorée [11] presented the simplest model with a “send/receive” style for depositing and withdrawing knowledge from the database. Later, more practical operations about the issues surrounding the databases of LL were researched. Jessop et al. [36] used a patterned language to enable lessons to be structured in terms of issues, contextual relevance, forces at work, solutions, new context and additional background information. However, their study only encouraged the use of experts and advisors for the initial database’s creation from lessons that are already gathered instead of focusing on the knowledge owner (sender) and receiver. There also exist many conceptual solutions without the particular problem faced in digitalization by an organization. From the organizational learning view, Argyris and Schoen [37] first introduced the double-loop learning model, which concerns the single individual learning system and the collective organizational capability for improvement. This was followed by the further conceptualization of the knowledge life cycle by intertwining single- and double-loop learning processes [26]. Later, McClory et al. [38] conceptualized triple-loop project learning with a focus on the project’s process and its situation and comprising personal learning, project learning and organizational learning. In project learning, Williams [9] (p. 262) called for “wider research into how lessons [from projects] can be disseminated throughout an organization and incorporated into organizational practice”. Pioneering researchers [10,11,16] investigated conceptual solutions for the transfer of knowledge across projects and from projects to the organization. One particular LL knowledge model for project learning by Duffield and Whitty [16] consists of six individual elements: learning, culture, social activities, technology, process and infrastructure.

While the majority of prior research identifies the requisites for successful LL management, it fails to address the customization problems faced by project learning in an organization. Customization will be central to enable effective LL management due to the “learning paradox” that organizations suffer from in project learning [10,11]. The learning paradox refers to the tension between knowledge creation and disappearance because projects are contextual and temporary in nature [10]. Hartmann and Dorée [11] highlighted the need for a project learning approach that considers contexts through “which projects are formed” and “which is constantly produced by project activities”. Customizing LL flows that deliberately coordinate the organization’s social-technical resources according to the contextual features of project can thus help navigate the tension. Moreover, most extant discussions regarding LL management in projects focus on high-level theoretical frameworks rather than the guidance of detailed actions towards digitalization.

Two critical issues are essential for digitalizing the LL management in projects and are yet left unresolved. The first is the design of the customized LL flow of project into an organizational process (for complex systems development project in our context) [14,16,39]. This requires proper process designs for identifying and cultivating LLs that are possessed by individuals and transforming them into shared assets that may be leveraged to improve a project’s performance [14,40,41]. The second issue comprises ensuring that customized LL flows are implemented in a competitive manner. The important task is to effectively convert the customized flow into the digital platform. To achieve these, a proper working approach is required that bridges theory and practice [17,28,42]. In response, we propose the following human-centered digitalization approach geared towards solving these problematic tasks.

2.4. The Proposed Human-Centered Digitalization Approach

Given the origins of experience-based human interactions taking place between individuals, LLs in a complex systems development project are managed via the knowledge flow by which we manage related human-based assets [31]. Because of this, digitalizing the LL flow should help guard and grow the required assets into a form that can be more readily shared by other participants in a complex systems development project [43]. Huysman et al. [44] described a collective acceptance of shared learning as critical for generating value for future systems developments. Convincing participants to share, access and reuse the captured LL is the key, and the digitalization of these activities provides a potential solution to the challenge [1,17,25,28]. Duhon and Elias [45] reported that failing to learn lessons in a complex systems development project can be connected to human-related cultural and social factors. Managing human-related factors is, therefore, both a problem and a solution for digitalizing LL management.

The core of the proposed “human-centered digitalization” is to systematically address relevant human-related factors in our intended LL management. Problem solving is conducted through the lens of systems design and bridges the gap between the problem and existing undesirable situations in manageable ways [46]. In the lens of systems design, we should treat problem solving for human experience with regard to digitalizing LL management as a “black-box” system and a design goal [35,46]. According to Buchanan [47] (p. 86), “a system is a relationship of parts that work together in an organized manner to accomplish a common purpose”. The systems design efforts are to meet relevant human needs as a key purpose and this is achieved by designing system parts and their interfaces.

In line with this requirement, the working approach for how to implement human-centered digitalization synergizes the two seemingly independent problem-solving approaches that are inspired by design (thinking) and systems (thinking) theories [47,48]. The design theory is concerned with various theoretical approaches towards understanding and delineating design principles to guide why we do the things we do, whereas systems theory seeks to develop and explain why the things we do worked or did not work around the systems and the way they relate to each other to permit a larger whole and more complex system [47,49]. Both theories have been applied in numerous academic and practice settings in solving social-technological problems, which are thus pertinent to our study.

The two approaches employed here have shared roots with respect to their epistemological foundations of pragmatism in systems design [50,51]. Both of them begin with human needs identification and end with solutions that satisfy those needs. Well-known approaches in design theory include human-centered design, also known as design thinking [52]. The standard ISO 9241-210:2019 [53] appointed human-centered design as a working approach that can increase the usability of systems by focusing on the human needs of the system. The human-centered design approach has the proven advantage of effectively innovating in the context of uncertainty [52,54], but it has been mainly applied to the fuzzy front-end development of systems instead of the entire system’s life cycle. On the other hand, most problem-solving approaches in systems theory adopt systems thinking in some specific relation to human-engineered systems across their life cycle [55], and systems engineering is one of them. According to the standard ISO/IEC/IEEE 15288:2015 [56], the systems engineering approach consists of technical processes with a wide coverage across the system’s life cycle that are used from the initial definition of the requirements for a system based on stakeholder needs until the disposal of the system when retired. The systems engineering approach has the advantage of dealing with complexity during the entire system development project, but its implementation requires the input of intense creativity from human-centered design efforts [57]. These two approaches, originating from either design thinking or system thinking theories, have their own advantages and disadvantages that can complement each other [47,48]; thus, they can jointly serve as the theoretical basis of the human-centered digitalization approach. Based on the interdisciplinary literature across design thinking and systems thinking theories, the synergies are delineated and adapted in terms of design principles in the human-centered digitalization approach according to the research tasks in this study.

2.5. Design Principles for the Human-Centered Digitalization Approach

Design principles are known as the sets of rules that guide decisions and practices in arriving at plausible systems designs. Let us take design thinking as an example: The principles (i.e., human-centeredness, problem reframing, visualization, experimentation and diversity) are mostly applied to creative teamwork in systems design [58]. In real-life practices, there exist many variations regarding the degree or to what extent each principle is applied and their choices are contextual. The popularity of design principles is due to its co-existence in and bridging of both the academic and practical worlds. In our context, each design principle is necessary for successful LL management for complex systems development projects. The design principles each represent a vital dimension, i.e., mindset, viewpoint, process and performance. Using these can guide situated actions leads to an eventual solution for the customization and digitalization of LL management. The four design principles are derived from the extant literature based on the combined effects of design thinking and systems thinking inspired approaches.

2.5.1. Mindset Dimension: The Capacity to Understand Others and to Start to Solve Problems from Their Perspectives

A thorough understanding of human-centered needs is the baseline of problem-solving in both design thinking and systems thinking inspired approaches [52,59]. The first notable design principle is to be “human-centered”. This principle originated in design theory [35,52] and is applied in our context due to the human-centeredness of LL management. It focuses on people and not only the ones who are the recipients of the knowledge (i.e., the LL in our context) but also the ones who created them in the first place. Problem solvers are required to have awareness and empathy of what people experience, including emotions, values and actions as well as meaning in operational contexts, and the ability to frame problems or opportunities based on problem solvers’ points of view from those experiences [52,60,61]. Researchers developed new methods and practices for problem solving for human experiences, such as observations, interviews and participatory design [35,62,63]. For instance, engaging the people for whom the solution is designed for has been a common method used in participatory designs to better understand human experience and create solutions for any issues.

2.5.2. Viewpoint Dimension: The Capability to Understand the Situation as the Complexity of the System Increases

For a given system of interest (i.e., intended LL management) that is complex, it is necessary to have a helicopter view of all the components or systems that interact with and in a way that is unifiable and explainable [5,10,31]. Design research attributes an organizational learning system to the interactions between individuals and their situation or the outer environments they created with emerging technologies [32]. As part of organizational practices, LLs involve both internal and external factors that result from human interactions with other systems and the environment. For instance, the knowledge flow of LL for complex systems development projects is considered as only one system that is designed among many other knowledge flows in an organizational context. To have a “holistic view” as the second design principle is thus critical for customizing the knowledge flow.

Systems thinking researchers perform many holistic approaches for unraveling complexities in systems design [55]. It mainly focuses on bridging the identification of needs and the system’s design that fulfills them effectively and efficiently. Those approaches, such as systems engineering, adopt systems thinking to articulate the reasoning for systematically creating and applying the relevant systems design processes [5,55,56]. It is a common way of thinking that can be used for reverse engineering the reasoning of customized knowledge flows in order to keep its fit with the overall interest of the parent system (i.e., an organization in our context) [64].

One commonly used tool to enable a holistic view is the process mapping. A process map provides the reader with a graphical description of a process from start to finish. As Muller [65] (p. 7) defined, a process is “an activity which takes place over time and has a precise aim regarding the result to be achieved. The concept of a process is hierarchical, which means that a process may consist of a partially ordered set of subprocesses”. Thus, process maps can be illustrated in different ways, e.g., workflow diagrams, detailed process maps, value stream maps, swim lane maps, high-level process maps, document maps, etc. [66]. Based on the process map of an organization’s overall workflow, a holistic understanding can be achieved to the context in which LLs reside and for furthering a conceptual design of new or improved LL flows for complex systems development projects.

2.5.3. Process Dimension: The Methodology to Apply in Which a Situation or Issue May Be Analyzed and Solved

As a widely adopted problem-solving approach within systems thinking, systems engineering helps create and execute a systematic process to ensure conceptual designs, and their realizations satisfy customers and other stakeholders’ needs in a trustworthy, quality and efficient manner throughout a system’s entire life cycle [5]. The essence of this approach is a systematic yet relatively convergent approach that validates and verifies the design against any elicited needs during the working process. However, it requires activities focusing on a great deal of interdependent components or factors in complex systems design and the way impact each other, which is a daunting task. To the contrary, the design thinking inspired approach, human-centered design, follows a more divergent and creative path for problem solving. These design efforts concentrate a task-based workflow around the problem and effectively generate solutions, which excel in face of chaos in a complex systems development project. The initial studies [47,48] asserted that synergy effects between the two approaches can promote creative systems design while reducing the complexity entailed by future systems development. To achieve the combined effects, it is beneficial to synergize the corresponding actions into a systematic task-based path for better execution in terms of the human-centered digitalization approach. Based on that, streamlining the systematic task-based path is the third important design principle.

There exist many task-based paths that guide creative systems design efforts. The design thinking framework is a well-known one [60,61,67], and it is mostly applied in single-product innovation for users’ needs satisfaction. It follows an overall path comprising three phases, including a. understand, b. explore and c. test [68,69]. Moreover, it mainly contains five key activities in the overall path: a. understand—(i) conduct research to develop an understanding for user needs; (ii) combine the research and observe where users’ problems exist; b. explore—(iii) generate creative ideas; (iiii) build prototypes for winning idea(s); c. test—(v) return to the user for feedback on the solution. Based on this well-structured path, we further integrate them with systems engineering activities in order to tackle complexities during the system’s design for our intended LL management. Hence, the first main task, a. understand, should contain a series of systematic activities ranging from need finding to problem framing for the systems design, including stakeholders’ identification, stakeholder needs elicitation, the “As-Is” status analysis of the systems of interest, root cause analysis (RCA) and improvement or innovation opportunities identification. According to the INCOSE Handbook [5], stakeholders generally include all people or organizations that can affect or can be affected by the utilization or performance of the system’s design. The identification of stakeholders, stakeholders’ needs elicitation and potential co-participation can provide important means to analyze the current system status of the systems of interest. The current system’s status analysis investigates the “As-Is” situation of the system elements and their interactions within and with the environment in which they are placed, conducts an RCA of the undesirability of the “As-Is” situation and eventually identifies improvement areas. Due to the advantages of creativity and the overlapping purpose of forming ideas from conception to implementation, the second task, b. explore, should include similar activities to the design tasks (iii) and (iiii). All relevant design methods and practices thus can be well applied while ideating, experimenting and reflecting on conceptual solutions. Besides the implementation details of systems engineering activities, the third main task, c. test, should involve more systematic validation and verification activities in (v) not only for meeting stakeholder needs but the parent system’s interests. By following the above task-based path, the solution in terms of new or improved LL flow can be generated to benefit project learning and to meet overall organizational learning objectives.

2.5.4. Performance Dimension: Performance-Driven Actions towards Optimal Capability Building in Implementation

Implementing the new or improved LL flow is a notable challenge for an organization, and this is related to people’s attitude, behavior and participation. The temporal nature of the social context in project learning sets barriers for sustaining the effective creation and dissemination of LL [10,11]. In spite of a well-developed LL flow, the persistent quest towards the implementation’s success has led to the consideration of using emerging technologies to promote engagement and collaboration. Digitalization efforts can enable creators in registering and storing information on what is learned, and the recipients can access and reuse past learnings in a convenient and a timely manner. Among the efforts, both design thinking and system thinking researchers advocate the importance of feedback from both creators’ and recipients’ experiences with respect to solution implementation, such as user interfaces, usability and engagement in systems design in comparison to technological issues [5,35]. Melendez et al. [70] further posited that human-centered feedback helps learn from prior interactive experiences for future complex system development projects. Conventionally, the collection of feedback as part of the LL occurs at the endpoint of the project [5]. However, learning lessons from the past is a continuous process, and its benefits are embedded throughout a complex systems development project. Similarly to LL, project risks may emerge during any point of the system’s development. PMBoK [20] highlighted that despite the high uncertainty at the start, the mitigation of applicable threats is less expensive in comparison to later stages of the system’s development. Thus, it is beneficial to start risk management by using LLs as early as possible in a project [71,72]. Instead of a focus on the endpoint, LL implementation should in fact be the first and principal point at which we can start and plan the development of complex systems. Moreover, Paulzen et al. [73] highlighted that the quality of the relevant solution implemented should enable continuous improvements and the self-optimization of the developed knowledge flow. Therefore, the fourth design principle is to have a continuous process throughout a complex systems development project.

3. Data and Methods

We adopted a case study method to illustrate the application of the proposed human-centered digitalization approach and its four design principles in real-life practices. The key purpose is to advance the in-depth understanding, interpretation and discussion of its application on the customization and digitalization of LL management for complex systems development projects within an organization. A case study is known as a strategic qualitative research methodology and has proven to be a rich method to investigate a single case [74,75]. The case is commonly intended to focus on a particular issue, feature or unit of analysis instead of an entire organization [76]. As our main research method, a case study encompasses a detailed investigation with real-life data collected from a well-defined case involving automated systems projects for maritime industries [77]. This method enables us to provide an analysis and explanation of the context and processes involved around the intended LL management in a real-life setting.

The organization in the case is an established international company that delivers integrated solutions through their automated systems projects for maritime industries. These complex systems development projects provide fully integrated solutions that are suitable for on- and offshore, merchant marine, subsea, navy, coastal marine and aquaculture markets. The starting point of this study was the case’s organization has a need for a structured method to digitalize the LL for the automated systems projects in order to maintain the quality requirement of ISO 9001 standards and a competitive edge in marketplaces. As an ISO 9001:2015-certified organization, the case’s organization must have procedures and methods for conducting LL management to fulfill the specific requirements for quality management [78]. The case’s organization defined processes for conducting LL as required by ISO 9001:2015 but faced challenges with respect to how to share and reuse LLs. The case study is performed in the department specializing in automated systems projects. The common practices involved in this case include conducting LL at the finishing phase of a project and under the request of project managers when a project is delivered. However, no agreed upon knowledge flow of LL was present, so not every participant in the complex systems development project, e.g., engineers, lead engineers, project managers, etc., could be engaged in contributing and benefiting from LL during the project’s execution. Furthermore, the documented LLs have been stored in a related project folder on a local server that requires special access. As a result, there exist too many technical platforms where the LLs are located, and this causes an extensive knowledge gap for learning within the case’s organization.

To conduct the case study, we applied participatory action research (PAR) design [79] to link every stage of the research and action in a real-life setting. This was able to be realized only via close collaboration between the researchers and participants. The partnership with the local system’s designer who had insider knowledge of the case’s organization was integral to the success of interpretating the design principles (of human-centered digitalization) that were to be applied in the case’s specific contextual situation and cogenerating the case’s findings. Because of this, our case study’s research design exemplified the concrete and contextual implementation of our design principles [58].

The case study began with streamlining the research process into a systematic task-based path, as shown in Figure 1, which reflects the synergy effects of the two aforementioned problem-solving approaches in referring to Design Principle 3. All other design principles are executed among the research activities in the case study, as shown in

Table 1. The applicable design principles of human-centered digitalization approach in case study.

Research Activities	Main Design Principles Applied
Problem Statement	D1. Through empathy to understand and frame the problem
Stakeholder Identification	D1. Through empathy to identify stakeholder and their needs
“As-Is” Situation	D2. Through process mapping to understand system status (incl. components and interactions within system and with other systems)
Root causes analysis	D1. Through empathy for a deep dive into the root causes regarding stakeholder needs behind an undesirable situation D4. Through performance barriers for identifying improvement areas
Solution	D1. Through co-creation for solution ideation (i.e., systems design) D2. Keeping the systems design’s fit to the digital organizational context D3. Through visualizing detailed actions for better co-creation D4. Through integrating continuous process and feedback in the systems design and solution optimization
Validation	D4. Through feedback to validate if the solution solves the problem

.

The research activity starts with goal setting or problem statement alignment for this case study. The first problem-solving workshop in the case’s organization was conducted in this initial phase for problem validation. Design Principle 1, “human-centered”, was applied by encouraging awareness and empathy, which enables the workshop’s participants to unfold the problem. With a validated problem, the next activity was to identify the relevant stakeholders. The group interview was conducted in the case’s organization for identifying stakeholders and their needs. Referencing Design Principle 1, these stakeholders and their needs were elicited by empathetically understanding human needs with respect to their experiences about the current LL management for automated systems projects. The following activity was to further investigate the existing knowledge flow of LL in the automated systems department. By reviewing existing procedures, a process map of the workflow was created to describe the “As-Is” situation. With a holistic view (Design Principle 2), the process mapping provided a graphical overview of the workflow in terms of automated systems projects and its linkages with other relevant workflows in the operating environment. Based on that, a root-cause analysis can then be executed to seek the root causes of why the case’s organization has an undesirable situation in the LL management for those projects. In considering the performance dimension (Design Principle 4), improvement areas can initially be identified. The application of Design Principle 1 using empathy can further help unpack in-depth human needs behind the undesirable situation. As a result, we discovered 18 root causes based on the interview data with stakeholders. The solutions were co-created with the stakeholders to address the root causes, and we also applied Design Principle 1. A series of workshops with the stakeholders were conducted for solution generation, optimization and eventual validation. Generating solutions involved detailed actions for managing LL as a continuous process through the project (Design Principle 4) and having a fit with the existing organizational digital platform (Design Principle 2). In the process of cogenerating the solution, those detailed actions were visualized in terms of a systematic task path for improved co-creation and final execution (Design Principle 3). The feedback received from the co-creation workshops served as important sources of solution optimization (Design Principle 4). The feedback received from the validation workshop also confirmed the importance of Design Principle 4 in managing LL as a continuous process throughout the project.

Both primary and secondary data have been used in this research. The secondary data were collected from the websites, project reports and procedures of the case’s organization, which provided sufficient evidence to aid the process mapping in analyzing the “As-Is” situation. The primary data were collected through interviews and workshops in the case’s organization. Interviews are commonly used data methods for gaining an understanding of the interviewee’s knowledge and perceptions, which helped collect detailed information [80]. Workshops have been used as a qualitative research method in various problem-solving contexts. It is known that workshops enable a creative and inclusive space to address specific topics via the interactions of participants [81].

Both interviews and workshops vary in types and structures. The data from interviews and workshops can be used as evidence of people’s perceptions and understandings. It is thus important for the interviewers or workshop facilitators to have insider knowledge regarding automated systems projects in the case’s organization to collect and interpret the data [81,82]. By collaborating with the system’s designer in the case’s organization, the execution of data collection and analyses can incorporate local knowledge to arrive at the best results [79]. The execution details are shown in

Table 2. Primary data collection methods.

Expected Goals	Data Sources	Participants
Problem identification and validation	Kick-off workshop	1 Director, 2 Department Managers
Eliciting the list of stakeholders and needs	Group interview	1 Director, 2 Department Managers
Understanding “As-Is” situation and the root causes of elicited needs	One-to-one interviews	1 Director, all 5 Project Managers, all 4 Lead Engineers, 1 Sales contact and 1 Customer Support contact
Conceptualizing solutions to the root causes	Co-creation workshop	1 Director, 1 Department Manager, 1 Project Manager and 1 Lead Engineer
Reviewing solution for improvements	Feedback workshop	1 Director, 1 Department Manager, 1 Project Manager and 1 Lead Engineer
Validating the solution for the implementation	Evaluation workshop	1 Director, 2 Department Managers

, including the expected goals and the corresponding data sources with participants. The participants are carefully selected due to their ample experience with project implementation in automated systems development within the case department. The key contacts from the sales department and CS serve additional sources for data collection.

4. Case Study and Results

This section reports the results from the streamlined research activities in the case study.

4.1. Problem Validation

In the first group workshop (Design Principle 1 applied), the research problem was discussed and validated against the situation of the case’s organization. The validated problem statement, how to systematically develop the customized knowledge flow of lessons learned (LL) and digitize it for improved project performance of complex systems development, was documented in a Continuous Improvement Process (CIP) document in the case’s organization. A CIP mandate is a tool for addressing internal challenges and coming up with problem-solving proposals. The participants in the workshop became the supervisors of this in-house research project in the case’s organization.

4.2. Stakeholders and Stakeholder Needs

In reference to Design Principle 1, it is essential to know who the relevant people or parties are (i.e., stakeholders) and to capture their needs in digitalizing LL management. By conducting group interviews, the stakeholders were elicited (listed in

Table 3. Stakeholders and stakeholder needs.

	Stakeholders	Stakeholder Needs
Knowledge Owner	Direct: Project Manager Indirect: Customer Support, Sales Department	An agreed process for creating LL A common digital platform for LL storage A systematic way to track LL cases
Knowledge User	Direct: Director, Department Manager, Project Manager, Project Engineer, Lead Engineer Indirect: Customer Support, Sales Department, and other Delivery, Product, and Quality Departments	To have a common digital platform for retrieving knowledge in the form of LL To have a user-friendly interface of the common platform To be able to easily identify the LL cases

). In view of automated systems projects, stakeholders were cataloged into two groups: knowledge owners (creators) and knowledge users (recipients). In each category, we further identified the direct and in-direct stakeholders. Direct stakeholders included participants in the automated systems projects and included research data collection, and indirect stakeholders were outside the automated systems department and not directly included in data collection; they would be relevant for further research beyond the project level. All knowledge owner and knowledge user needs have been taken into account during the solicitation of stakeholder needs by the supervisors of this in-house research project who participated in the group interview, which are also presented in Table 3.

4.3. The “As-Is” Situation

There are existing procedures to conduct LL. In reference to Design Principle 2, the workflow mapping for automated systems projects in the case’s organization provides a useful overview of what is defined in the procedures and how LLs are performed in real-life. Based on the case’s organization’s procedures and the interview data, the “As-Is” situation was mapped in the form of a graphical overview of the “As-Is” workflow, shown in Figure 2. The graphical overview shows each project’s phase milestone, typical tasks to be conducted in each phase, routines for storing information and knowledge flows from each phase, including the knowledge flow related to LL. In Figure 2, the “blue” line illustrates the flow of knowledge. The “magenta” line illustrates the flow of previous LL documents, and the “yellow” line illustrates the flow if a new LL case appears.

The existing workflow consists of six phases of the automated systems projects, including start-up, planning, engineering, production and testing, commissioning and closing. In order to gain a more holistic understanding, the sales phase before the start of the project in the automated systems department and the closing phase when developed systems are operative has been included:

• Sales phase: The sale phase is where customers’ needs are identified, which is derived from the development of the systems requirements. Based on the experience from previous and similar projects and inputs from the customers (i.e., shipyard in our case), the system’s development requirements can be firstly generated and validated, and then the cost of design concept can be estimated and presented to the customer.
• Start-up phase: The sales manager prepares and hands over all documents, such as contracts, purchase orders, requirements and sales calculations for the cost, to the director who owns various projects. The director is responsible for appointing a project manager and handing over those documentations, which are all performed digitally. A project manager is then responsible for carrying out a pre-risk assessment.
• Planning phase: The project manager establishes a project plan according to the given budget (P-Calc) and contractual obligations. Once all resources are allocated to the project, a kick-off meeting is held with the project manager, hardware (HW)/software (SW) lead, HW/SW responsible and other engineers. According to the case’s organization’s existing procedures for this phase, the previous LLs should be considered as topics during the kick-off meeting. The risks can be brainstormed and identified based on earlier experiences in relevant projects, such as LL. The gathered risks can be stored in the project folder. However, locating the LLs was difficult.
• Engineering phase: The customer (i.e., shipyard) and the third party (i.e., suppliers) hand over the system’s development requirements. System requirements are transferred to HW drawings, SW functionality documents, piping and instrument lists (P&ID) and input/output (IO) lists of all the signals that require connection, which forms the basis of the SW’s development and graphical user interface. During the engineering phase, there is back-and-forth communication with the director, shipyard and suppliers to ensure that the automated systems were developed as required. All relevant communications were conducted via e-mails, meetings/workshops, or phone calls. After meetings/workshops, a minute-of-meeting (MoM) document was made and stored in the project folder.
• Production and testing: HW and SW productions are finalized in this stage with an Internal Acceptance Test (IAT) before a Factory Acceptance Test (FAT). FAT is performed with the director, customer (i.e., shipyard), third party (i.e., suppliers) and class company to ensure that the systems are working as intended and accepted. An MoM document after FAT is performed and stored in the project folder. HW equipment is shipped for installation, and SW files are handed over to the local site’s office.
• Commissioning phase: The case’s organization is directly involved in the installation or as a supervisor. The commissioning phase is finalized by a Customer Acceptance Test (CAT) for verifying the system’s requirements, and the validation of the system in its environment is conducted at sea trials and gas trials.
• Closing phase: After the gas trial, the project is handed over to Customer Support (CS), which means that the project is completed from the delivery side. CS will handle all incoming warranty claims from the customers. The only LL meeting called by the project manager is after the developed systems completed commissioning or before the handover to CS in the closing phase. There has been a lack of feedback from CS for the automated systems department afterward.

If an additional change is requested by the customer (i.e., shipyard) during the project that is beyond the original project’s scope as defined by the Variation Order Request (VOR), the project manager becomes involved, and VORs are stored in the project folder with an attachment of the Project Change Register (PCR). This is a database for registering and tracking changes.

In reference to Design Principle 4, the initial analysis of the “As-Is” situation helped identify a few key issues or improvement areas in current LL management processes, including LL meetings, LL storage and the feedback loops of LL.

• LL meetings: Current LL meetings are only held at the project’s end phase. The aim for the current LL meeting is set to reflect on project-specific work. Prioritizing LL at the end of each project requires each project’s participant to remember all issues that occurred during the project’s implementation and to convey these based on their interpretations during LL meetings. Important knowledge from the LL meeting to share with the sales department is related to technical challenges, over-consumption of hours, purchase costs or customer relationships. HW or SW leads are responsible for the technical-related LL cases registered in the problem and improvement database (P&I). When a P&I is registered, it is sent to the product department.
• LL storage: The documentation of LL meetings is stored in the project folder, which is only available on a local server. The workflow mapping demonstrates the lack of an effective method to enable knowledge users to access the stored lessons. Furthermore, the current focus on LLs in the project’s endpoint causes many LLs to remain within the individual participants or they are only shared with some informally.
• Feedback loops: The knowledge flow from CS back to the automated systems department is highly desired, but it is not in place. After the automated system is delivered and operative, CS handles all relevant feedback. Feedback regarding warranty claims about the system’s delivery and operations should serve as useful insights for potential improvements in future systems development.

4.4. Root Cause Analysis

The initial analysis of the “As-Is” situation identified the above key issues to be solved in the case study. One-on-one interview sessions with key stakeholders were carried out to further investigate the root causes of those key issues. The mapping of the “As-Is” situation served as a basis for designing the 23 questions in semi-structured interviews with the participants from the automated systems department for the root causes analyses. The informal interview sessions with one representative from the sales department and one from the CS were conducted for understanding the knowledge flow among the sales department, CS and the automated systems department.

Root cause analysis is one of the most useful tools for solving various industrial problems, such as quality and productivity, safety and accidents [83]. Referencing to Design Principle 1, two rounds of analyses were conducted to find the root causes of why LLs are difficult to share and reuse for automated systems projects. The first round of interviews focused on the inquiry of the internal routines of LL usage, knowledge flow of LL and possible improvement areas. The second round of interviews with the same participants as the first round was directed towards a desired systemic way of sharing LLs. The collective results are presented in

Table 4. Root cause analysis results of lessons learned (LL) management.

Category	Root Causes
People	Sharing LL depends on individual initiative No experience with LL Cultural differences Lack of time to document LL during commissioning
Methods and Tools	No quality assurance of LL input No follow-up of LL through each project phase No structured methods to store LL Too many templates for documenting LL Lack of common templates No tracking LL progress Difficult to locate the previous LL
Procedures and Processes	Current LL task is only performed among project managers Current process flow describes LL to be conducted only in the end phase of a delivery project
Communication	Lack of knowledge transferred back to the project team LL sharing between departments is limited to a few key contacts and not available to others Lack of LL inputs that sales could miss, e.g., the cost estimate No feedback loop after the handover of the system to Customer Support No systemic way to create and identify LL

. The root causes were cataloged into four categories: People, Communication, Method and Tools, and Procedure and Processes and the case department’s communication with other parts of the organization today.

4.4.1. People

Since the case’s organization is a global company with employees and customers all over the world, there exist cultural differences not only when communicating with customers but also between participants of the automated systems project. According to Ramachandran [84] (p. 501), “different groups may prefer different problem-solving styles and have different beliefs about the causes of problems”. The case department experiences differences from one site office to another in terms of giving feedbacks and sharing LL. Besides cultural differences, there is often a time constraint during commissioning, such as the experience of LLs and a formalized way of managing LL throughout the automated systems project. We found current LL sharing mainly depends on individual initiatives. This is a result of the fact that there is a lack of systematic management operations and a common platform to store, share and trace LLs that are registered. This also corresponds to one of the root causes listed under communication.

4.4.2. Methods and Tools

The most mentioned causes in the interviews were no structured methods and tools to store and share LLs from previous projects. In 2020 and 2021, the automated systems department delivered about 90 systems for installation in vessels, among which the majority of the deliveries can be cataloged into over 20 series of vessels. Each automated systems project can consist of a series of vessels where the first vessel in the system’s delivery lays the foundation for upcoming sister vessels. The sister vessels are, in general, built to be identical to the first vessel with the same tailored SW and HW systems delivered from the case’s organization. The common practice is to conduct LL tasks on the first vessel. If a change occurred from the first delivered vessel, LL tasks would be carried out before the delivery of the last vessel. The project folder for each project delivered was used to locate the LL document, and it contains a list of delivered vessels. Figure 3a shows the total number of series vessels delivered (in blue) with the related LL (in orange). It is found that LL documents cannot be located in 14 of these series delivered. Figure 3b shows the total number of single vessels delivered (in blue) with the related LLs (in orange). Among the single vessels delivered, only four vessel projects had LL documents stored on the server. Thus, there exist missing LL documentations for half of the total projects, which further explains why LLs are difficult to locate. In projects where LL documentation was not found, an informal LL meeting may have been conducted, but the outcomes were not stored. With adequate methods for storing and registering LL cases, such as adopting a common digital platform, improper storage or allocation could have been avoided. By setting various search criteria in the digital platform, knowledge users will be able to locate the LL. Moreover, the missing LL documents of various projects, including both series vessels and single vessel deliveries, were attributed to manual sorting and check-up procedures. This also is a time consuming method for reusing the stored LL, as it can easily take several hours to manually search each of them for required documentation. Therefore, two key stakeholder needs are to have a common digital platform for LL storage and user-friendly tools for required searching.

4.4.3. Procedures and Processes

In the case’s organization, there are many business processes and templates related to LL management. This makes it difficult and frustrating for both knowledge owners and users to navigate to a certain process and template. For instance, when a user clicks on one of the process blocks, it may contain four different templates to register and conduct LL. Based on the interviews, we found there is no system guarding LL tasks except for the specification of LL performed at the endpoint of the automated systems project. The participants of the LL meeting at the endpoint are limited to the invited project managers.

4.4.4. Communication

The most common form of communicating LL within and between the automated systems department and the other departments, such as the sales department, CS, etc., is via e-mail, phone calls or offline chat. These communication forms are suitable if there are only a few participants during a project but may not work for a complex systems development project that involves plenty of participants. Furthermore, current cross-department communication is mainly conducted by a few responsible contacts; it is thus impossible for most participants in the automated systems projects to have symmetric information. Both representatives from the sales department and CS pointed out in the interview that the communication flow of the LL among the automated systems department, sales and CS should work as a continuous “triangular” model and yet has the potential for improvement. For instance, the automated systems department can provide inputs on where sales could miss their estimate against customers’ needs. Only with these inputs can sales conduct internal LL meetings for solutions to improve estimates for customer needs. Moreover, feedback received from CS after the delivery of the automated systems should loop back to the automated systems department.

Project managers who lead LL meetings within the automated systems department pointed out a key cause of the problem when reusing LLs. It is important to be aware of the “value” of the LL so that participants are motivated to use them for future systems development. Since not all LLs are equally important, the LL cases are flagged in LL meetings. Their experience is that the identified status on the flagged LL cases have not been well-used. This is because there is no system for people to track if the sorted LL cases have been flagged as valuable or not. Besides, one of the lead engineers shared his experience that LL cases are often poorly formulated. This makes it difficult to understand what the issue was, why the issue occurred, and what actions can be taken to prevent the issue from occurring again. It is therefore important that the participants have guidance in how to make proper LL cases that can provide valuable data. In our case, the guidance should be facilitated by a systematic method for registering LL cases and describing the steps to ensure that valuable inputs are well-documented and tracked.

4.5. The Solution

Based on the co-creation workshop, the customized solution for the automated systems department was generated. The first part of the solution focused on the first research task of redesigning the knowledge flow of LL and its related task to conduct LLs throughout each systems development phase. Each phase is finished with an LL meeting where relevant stakeholders were invited. This minimized the chance of knowledge loss due to late LL generation and implementation. The second part of the solution was to digitalize the corresponding LL management on the common digital platform of the case’s organization. Digitalizing the LL in registration, storage and access enabled the project participants and other relevant stakeholders to work with LL cases in “real-time” and to use a common platform for storing and sharing LL.

4.5.1. The Customized Knowledge Flow of Lessons Learned

In general, the solution reflects how experience-based knowledge is gained during a complex systems development project, properly managed and looped back to the knowledge users. Figure 4 demonstrates the customized knowledge flow of LL for the automated systems projects in the case’s organization. This figure is a graphical overview of where to conduct LL, the reuse of previous LLs and how the digital platform will be used during project implementation. LL cases are registered and retrieved from the digital platform. LLs marked as “flagged” or “non-flagged” are stored within the digital platform and are searchable by defined search criteria. Storing LLs digitally and defining users’ needs with respect to search criteria to collect relevant LL cases will result in a better knowledge flow of LLs within the case’s organization. In this way, the LL cases can be retrieved in a timely manner and used when needed.

The customized design of the LL flow is aligned with the design principles of the human-centered digitalization approach. This part of the solution was co-created together with both knowledge creators and users with a focus on human needs (i.e., stakeholder needs in the case) in LL management (Design Principle 1). It is mapped into the existing organizational process and fits the overall setting of the operating environment (i.e., the organization and its existing digital platform) (Design Principle 2). The visualization of the detailed actions in terms of a task-based path is helpful for the co-creation process (Design Principle 3). The newly designed LL flow is well-reflected as a continuous process throughout an automated systems project (Design Principle 4). Specifically, LL tasks start in the start-up phase, and an LL meeting is held after each milestone throughout the automated systems projects in the case study. After each phase, the project manager (PM) is the remaining responsible person that arranges LL meetings with the relevant stakeholders. The change from the endpoint focus of LL management to a constant follow-up after each milestone will decrease the risk of missing LL cases until the system’s delivery. This solution was one of the most favored proposals from the co-creation workshop. This is because it helps improve the quality outputs of LLs for future complex systems development projects. In addition, the feedback loops are added from the CS to the automated systems department. When the vessel is operative, all warranty claims handed over to CS, for example, due to poor SW logic or HW-related issues and how are they solved, are valuable for future system developments. After some years of operation, all closed LL cases regarding problem solving for warranty claims can be important learning sources for preventing the same issue from occurring in upcoming projects. To execute the solution, we further streamlined the working tasks, as shown in Figure 5. In this task diagram, the yellow blocks describe the project’s phases, and the blue blocks describe the LL tasks that require completion after each milestone. An orange block is added to the end of the task diagram with LL tasks when the delivered automated system is operative or during maintenance.

4.5.2. The Digitalization of the Customized Lessons Learned Flow

The second part of the solution was to digitalize the customized LL flow and facilitate the creation, storage and sharing of LL. Similarly, with respect to the first part of the co-creation phase, this solution was also cogenerated based on the workshop to meet stakeholder needs regarding the use of digital platforms (Design Principle 1 and 3). The case’s organization has existing digital platforms for sharing information, reporting warranty claims and registering project changes (shown in Figure 2). Since it is a unison digital platform adopted by most departments in the case’s organization, the second part of the solution should be developed to fit existing digital infrastructure (Design Principle 2). The solution is thus intended to be a sub-system integrated with existing digital platforms in the case’s organization. When the solution is integrated, the digital platform will be a common place for registering, storing, retrieving and tracking LLs and its relevant information, such as warranty claims and project changes, in the case’s organization. The benefits of registering LL cases directly in the digital platform are to enable the project managers and other participants to work in “real-time” with the LL in cases that occur. Further considerations of the insufficient usage of past LLs lead to requiring a proper human–machine interface design and criteria search as part of the solution so that this common digital community can be user-friendly for both knowledge creators and users when implementing LL tasks (Design Principle 4). For instance, the platform users will have the opportunity to easily save LL registrations as a draft and track the progress of registered cases. This solution also allows a user to update the LL case by simply changing the description through the steps specified in the registration manual. It was agreed in the workshop that a solution with a user-friendly interface for LL case registrations together with the various availabilities of the search criteria will accelerate the exchange of learning from past experiences and its potential reuse between knowledge creators and users.

This co-created solution was perceived with high usability and consistency with platform users’ needs. It contained three sub-solutions that streamline the working task paths for platform users. Each sub-solution is focused on one key perspective of digitalizing the intended LL management, including (1) LL registration, (2) user manual application and (3) search criteria.

Figure 6 shows the conceptual design of the LL registration in the digital platform. The solution allows the user to navigate within the project’s module, to select which project phases the LL cases are associated with and to directly register the LL case in the platform. The idea is that when a project phase is selected, a new page will occur where the user can select the “Lessons Learned (LL)” sub-module. By searching the sub-module, the user will navigate to the LL page for that specific phase. On this page, the users will have the option to create an LL case or to have an overview of registered LL cases. For example, when the sales department appointed a new lead, he/she could easily perform a search in the digital system and obtain a “heads up” from previous experiences on similar automated system deliveries at the same shipyard or with the same creator of the LL.

Figure 7 shows the high-level design of the user manual of LL registrations in the digital platform. A detailed manual is not presented in the paper, but it was developed for implementation. When selecting “Create LL case”, the pre-defined information will automatically be generated for that case. The auto-generated information includes the project number, owner (of vessels), shipyard (customer), IMO number (ID number) and which project phase is related to the LL case. These pieces of information will be key inputs for the search criteria on the digital platform.

After a platform user selected “Create LL case”, he/she could then start to add the manual inputs. The user will start by adding a description of a certain case. After the description is described, any observed symptoms can be added. Observed symptoms are background information about the LL case. A description of what the user believes is the reason for the observed symptoms is added under the cause section. This section may need a deeper root cause analysis during the LL meeting to capture what the root reason for the cause was. After the cause is defined, the user will mark whether this registration is a promoted or improved case. Some LL cases that describe the positive experience from the project’s implementation are categorized as “Promote”. Other LL cases that describe negative experiences that required improvements are categorized as “Improve”. After the LL case is categorized, the user can add recommendations for turning the observed lesson into a learned lesson. The next step is to select the severity of the case. Three options define the severity grade of the case: minor, major or critical. The higher severity grade towards a critical case should carry more lessons to be learned. After grading the case’s severity, it is important to list the set of stakeholders that are usually case-dependent. The stakeholder’s information will enable increasingly efficient knowledge sharing and case tracking from when it was reported to when it was handled. When a stakeholder is added, the user can choose to add additional information. For instance, the information of the departments enables the LL case to be transferred directly to where the stakeholder resides. The final step is to link the LL case to a related P&I, PCR or VOR or otherwise to save the case if there is no need for a link to other registers. After the case is saved, it will be loaded to an LL summary module, i.e., project module, as shown in Figure 7. In this module, it is possible to define various search criteria to find relevant LL cases.

As previously mentioned, the key to sharing and reusing LLs within the case department and across departments can be enabled by the search function in the digital platform. With the current method where LL cases are registered in a word document or an excel document and stored in various project folders, it would not be possible to easily locate and access to the desired LL. However, when the platform users completed all LL registration tasks (shown in Figure 7), the LLs are collectively stored in a database on the digital platform and are thus searchable by certain criteria. The platform users can filter and navigate to relevant LL cases by searching the index’s info: automated systems department, IMO-number, project number, severity, stakeholder, owner (of vessels), yard (customer of shipyard), third party (supplier), system (HW and SW), VOR and project phase. The criteria are outlined in Figure 8 as the search method for locating LLs in the digital platform. The “grey” blocks show examples of various options the user can choose to filter the search. The collective group of search criteria offer platform users a wide range of options to find the LL case they are seeking. The ultimate goal of this second part of the solution is to further digitalize the LL flow in a common platform for knowledge creators and users, where they can retrieve the LL effectively for their usage. Without a customized search function, the simple collection of LLs would increase time costs for knowledge recipients and eventually demotivate platform users from participating in LL tasks.

4.5.3. The Solution Review for Improvements

In the feedback workshop, all solutions generated from the co-creation workshop were presented. The same participants of the co-creation workshop were invited not only because they are good representatives of both knowledge owners and knowledge users but also because they have ample experience and insights in the development of solution. Based on the participants’ feedbacks, the improvement areas are identified, i.e., the high-level user manual and the search criteria (Design Principle 4). For the user manual, they proposed to link the LL case with PCRs, VORs and the problem and improvement (P&I) system. This was desirable as these linkages can provide larger overview for platform users in understanding why this LL case was registered. This indicates that “which project phase” the LLs were registered for should be automatically generated once an LL case is created. As for the search criteria, improvements for more possible search options were proposed to cover the cases of other system delivery departments beyond the automated systems projects in the case’s organization. All possible improvements were integrated into the above-presented solution, as shown in Figure 7 and Figure 8.

4.6. Solution Validation

Validation is important for the credibility of the research results. In order to validate the solution, we held an evaluation workshop and presented both part one and two of the solutions to the selected stakeholders. The director and department managers who participated in the initial problem identification and validation were invited to the workshop. In the workshop, they reviewed and discussed the solution and its value. As a result, they validated that the solutions can solve the earlier validated problem: “how to systematically develop a customized knowledge flow of LL and digitize it for improved project performance of complex systems development” in the case’s organization. They also pointed out that the solution can minimize the risk of errors reoccurring in future automated system projects by capturing LL earlier and sharing them with stakeholders who are responsible for making further efficient improvements for the project, attributing to Design Principle 4. It is highlighted that the solutions point to the important task of conducting proper LLs in similar complex systems development projects and having a systemic method for guarding the customization and digitalization of LL management from initial creation until reuse, which enhances an organization’s knowledge capital.

5. Conclusions and Discussion

This study aimed to contribute to the systematic management of LL or broader organizational knowledge for complex systems development projects in the digital realm [10,14,16,39,42]. Despite different focal points as knowledge management evolves over time, the three key challenges remain: people (who know), knowledge containers (what we know) and content (how to describe and organize knowledge for intended users) [6]. There has been a lack of an overarching strategy that addresses all three in the context of rapid digitalization and growing complexity. In response, this study digested the current understanding of the learning paradox that organizations face in the digitalization of in- and inter-project LL and focused on how to both theorize and practice the digitalization of LL management for complex systems development projects in an organization. Based on the synthesized evidence from interdisciplinary research across design thinking and system thinking theories, we introduced a new problem-solving approach of “human-centered digitalization” comprised of four design principles. The originality of this study is that it contributes to the interdisciplinary research by outlining the theory-based yet pragmatic approach in aiding the intended LL management. On one hand, we extend the application of the synergies between the design thinking and systems thinking inspired approaches to the problem-solving in digitalizing LL management for complex systems development projects in an organization. On the other hand, practitioners could benefit from the guidance of the proposed approach by translating and applying its associated principles to generate the customized and digitalized solutions for their LL management in the specific project and organizational contexts. We exemplified the application of the approach and its design principles through a real-life case study.

In a large organizational context, the case study is conducted with a focus on the intended problem-solving of LL management for automated systems projects. There are several important takeaways. Firstly, the findings emphasize the importance of customized solution developments that involve the stakeholders of both knowledge owners (creators) and knowledge users (recipients) who are often context dependent. Secondly, the use of digital technologies should enable the systematic management of LLs in meeting stakeholder needs. In our case, the digitalization part of the solution could not be realized by simply adopting new technologies but by also creating ways to make use of the existing digital platform, such as by designing proper human–machine interfaces based on the existing platform. Thirdly, all solutions should be geared towards capturing LL benefits for the intended users and the case’s organization. For instance, LLs should be collected in a timely manner to avoid being lost in the process, stored on one common platform to be easily located, and marked or flagged for easy recognition and search retrieval in order to promote the eventual reuse of knowledge. Moreover, the benefits of LLs in terms of risk management can be yielded by starting LL management as early as possible and throughout automated systems project instead of the conventional endpoint focus. Only in this way can the customized LL flow in the case’s organization stimulate a continuous learning process and aid risk mitigation during systems development. For instance, the risk of extra project hours on reoccurring errors could have been avoided by implementing earlier LLs, which represents a significant economic value for both the case’s organization and its customers. From the stakeholders’ evaluation, this study contributes to case’s organization towards a modern learning organization in digital times. Lastly, in order for solutions to achieve the intended results, it is important to ensure the involved tasks of customized and digitalized LL management are followed up in practice, the digital platform is user-friendly as user needs evolve and the search filters are continuously updated to be able to locate the desired LL.

At last, we acknowledge the limitations of the study and discuss the opportunities for future work in this regard:

• We presented “human-centered digitalization” as a problem-solving approach in digitalizing LL management for complex systems development projects and demonstrated its applicability in the real-life case of automated systems projects for maritime industries. An interesting extension to our study is to apply the approach in different complex systems development projects, such as in different organizations or industries, and to investigate if a change in settings from complex systems to non-complex ones would lead to different and similar findings.
• This study only focuses on one case study of one automated systems department. In a large company, many functional departments exist. Many departments, such as the commercial department in the case’s organization, may share similar needs for a common digital platform for storing and retrieving LLs. The case’s organization has long-term goal to have a fully digitalized solution that satisfies each department’s needs. It is, therefore, recommended that similar research should be conducted across different functional departments, which can yield an organization-wide solution.
• The solutions in the case study are validated for the intended problem-solving scenario. The next step is to obtain solutions that are verified for “how well the solutions perform” and to make a business case for implementing the solutions. Such an implementation may take years in a large company such as the case’s organization, and presenting the solutions as a business case by proposing a business plan for detailed planning and financing [85] is recommended.