LAPPEENRANTA-LAHTI UNIVERSITY OF TECHNOLOGY LUT LUT School of Energy Systems LUT Mechanical Engineering Aaro Kurkela DESIGN THINKING APPROACH FOR PRODUCT DEVELOPMENT PROCESS IMPROVEMENT Examiner(s): Professor D. Sc. (Tech.) Juha Varis D. Sc. (Tech.) Amir Toghyani TIIVISTELMÄ Lappeenrannan-Lahden teknillinen yliopisto LUT LUT School of Energy Systems LUT Konetekniikka Aaro Kurkela Tuotekehitysprosessin kehittäminen muotoiluajattelun menetelmiä hyödyntäen Diplomityö 2021 70 sivua, 39 kuvaa ja 10 taulukkoa Tarkastajat: Professori TkT Juha Varis TkT Amir Toghyani Hakusanat: tuotekehitys, prosessikehittäminen, design thinking, yhteiskehittäminen Tutkimuksessa käytettiin muotoiluajattelun mukaisia menetelmiä pyrkimyksenä kehittää tuotekehitysprosessia. Triangulaatiota hyödynnettiin yhdistämään tuloksia, joita tutkimus keräsi kirjallisuudesta, esimerkkitapauksena toimineesta tuotekehitysprosessista sekä tuotekehitysprosessin käyttäjiltä muotoilumenetelmiä hyödyntäen. Muotoiluajattelun mukaista yhteiskehittämistä hyödyntäen tutkimus muodosti kuvan esimerkkitapauksena toimineesta tuotekehitysprosessista ja ideoi kehityskohteita prosessin käyttäjien ja sidosryhmien kanssa. Tuloksena esitettiin havainnot prosessin nykytilasta sekä keskusteltiin ideoista prosessin kehittämiseksi. Triangulaation hyödyntämisen avulla prosessin kehittämiseksi pystyttiin esittämään myös kirjallisuuteen perustuvaa tietoa, sekä osoittamaan havaintoja prosessista kerätystä tiedosta muodostetuista kuvaajista ja kaavioista. Tulokset osoittivat muotoiluajattelun menetelmien kyvyn tunnistaa tuotekehitysprosessin osa-alueita, jotka aiheuttivat sen käyttäjille kokemuksia, joiden perusteella kehitystoimia voisi kohdentaa paremman arvonluonnin takaamiseksi prosessin kaikille käyttäjille ja sidosryhmille. ABSTRACT Lappeenranta-Lahti University of Technology LUT LUT School of Energy Systems LUT Mechanical Engineering Aaro Kurkela Design thinking approach for product development process improvement Master’s thesis 2021 70 pages, 39 figures and 10 tables Examiners: Professor D. Sc. (Tech.) Juha Varis D. Sc. (Tech.) Amir Toghyani Keywords: product development, process design, design thinking, co-creation The research applied design thinking methodology to improve the product development process. Triangulation was used to evaluate between literature review, case example process data and design thinking process result. The method provided credibility for the observations and helped to prove the capabilities of the design thinking approach as a product development process improvement method. The research formed a picture of the current state of a case study product development process and ideated possible improvements with users and stakeholders of the process. Results combined the observations of the process to possible improvement ideas created with co-creation tools. The triangulation method offered credibility to observations about the current state of the case example process and between literature and case example process data. Process data were plotted and presented as a graph and compared to design thinking process results and literature. The results proved the capabilities of the design thinking process as an improved method for improving the product development process. The design thinking method successfully identified parts of the product development process that caused user experiences that could lead to targeted process improvement actions to create more value for all users and stakeholders. ACKNOWLEDGEMENTS I must thank LUT University for the bold actions taken that made the Industrial Design Engineering programme possible. The journey challenged my thinking and values and ignited my curiosity for a more sustainable future by combining design and technology. This research was made possible by continuous support and knowledge generously offered by my supervisors Prof. Juha Varis and D. Sc. (Tech) Amir Toghyani. Similarly important was the trust and commitment to this process offered by the client company Veikkaus Oy and the expertise shared by its distinguished group of product development professionals and industry partners. Finally, I must offer my gratitude to all people involved in the insightful discussions during the research and to my family and friends. They helped to keep my bearings on the goal. Aaro Kurkela Aaro Kurkela 5 TABLE OF CONTENTS TIIVISTELMÄ ABSTRACT ACKNOWLEDGEMENTS TABLE OF CONTENTS LIST OF SYMBOLS AND ABBREVIATIONS 1 INTRODUCTION ....................................................................................................... 8 1.1 Research question .................................................................................................. 8 1.2 Research objectives ................................................................................................ 8 1.3 Research methods .................................................................................................. 8 1.4 Research scope ....................................................................................................... 9 1.5 Case example process .......................................................................................... 10 1.6 Literature review .................................................................................................. 11 1.7 Design thinking .................................................................................................... 14 1.7.1 Co-creation ............................................................................................... 15 1.7.2 Service blueprint ...................................................................................... 16 2 LITERATURE STUDY ............................................................................................ 17 2.1 Product development process .............................................................................. 17 2.1.1 Product data management ........................................................................ 19 2.2 Managing product development .......................................................................... 20 2.3 Concurrent engineering ........................................................................................ 24 2.3.1 Project management methods .................................................................. 24 2.3.2 Project management in businesses ........................................................... 27 2.3.3 Managing performance ............................................................................ 32 2.3.4 Measuring project performance ............................................................... 37 2.4 Process development with design thinking .......................................................... 39 3 PROCESS DATA ....................................................................................................... 40 3.1 Frequency of completed work ............................................................................. 40 3.2 Frequency of work in progress arrivals ............................................................... 40 4 DESIGN THINKING APPROACH ........................................................................ 41 4.1 Design thinking co-creation methods .................................................................. 41 6 4.1.1 User of the product development process ................................................ 42 4.1.2 Product development process as a service ............................................... 42 4.1.3 Theme interviews ..................................................................................... 43 4.1.4 Known challenges and possible areas of improvement ........................... 43 4.1.5 Digitalization ........................................................................................... 44 4.1.6 Questionnaire ........................................................................................... 44 4.1.7 Workshop ................................................................................................. 46 4.1.8 Service blueprint ...................................................................................... 47 5 RESULTS & DISCUSSION ..................................................................................... 47 5.1 Design thinking approach .................................................................................... 48 5.2 Frequency of work in progress arrivals ............................................................... 55 5.3 Frequency of completed work ............................................................................. 56 5.4 Discussion ............................................................................................................ 58 6 CONCLUSION .......................................................................................................... 66 LIST OF REFERENCES .................................................................................................. 67 7 LIST OF SYMBOLS AND ABBREVIATIONS Symbols σ Variability Abbreviations CAD Computer-aided Design CE Concurrent Engineering CPM Critical Path Method DFMA Design for Manufacturing and Assembly MAC Manager as a Coach NPD New Product Development PDM Product Data Management PERT Program Evaluation Review Technique R&D Research and Development RFQ Request for Quotation TOC Theory of Constraints WIP Work in Progress 8 1 INTRODUCTION This work aims to shed light on the issue of improving product development process results. The research is conducted by combining an engineering approach with a more creative approach that is design thinking. Design thinking has been proved as an effective tool when the problem includes complex systems, multiple stakeholders, and sometimes conflicting expectations between the mentioned stakeholders. 1.1 Research question With finite resources to use, companies need to choose how to improve established processes carefully. In today’s business environment, where success comes from the cooperation of multiple internal and outside stakeholders and implementing the right technologies, it can be a tedious task to find the correct areas of development that bring the best return for the invested resources. While existing research on manufacturing provides frameworks for identifying underperformance in specific systems, those methods do not translate straight to the product development domain. The problem seeks a new approach with a more holistic approach that takes different stakeholder needs into account. Design thinking approach validity as an improvement method is tested to determine its suitability to address this problem. 1.2 Research objectives This research aims to evaluate the validity of design thinking methodology as an approach to improve product development processes. The topic under investigation is the capability of this method to address multiple stakeholders in a modern business operation environment setting. The objective is to present process improvements that arise during the design thinking process, are supported by the triangulation, and are viable options for the case company. 1.3 Research methods The nature of the research topic and the question demanded an approach that combined information from multiple sources (Figure 1). The triangulation method depicted below is used for this purpose. The topic is first researched by reviewing related literature 9 (Beauregard et al. 2017, Cioffi, 2005, Lage Jr. & Filho, 2010, Markovitch et al. 2015). After this case, example process data is obtained for analysis and triangulation purposes. Last, the design thinking approach is used to conduct theme interviews and co-creation sessions to obtain relevant user experiences about the case example process. Following this design thinking approach is used to create new ideas and possible solutions for improving the process. After these research activities, the triangulation between the three sets of results is used to answer the research question. Figure 1. Triangulation framework. The gathered literature review could offer insight for further analysing the process data obtained during the research (Figure 1, “1.”). User experiences gathered with design thinking tools are compared to unconnected process data (Figure 1, “2.”). The literature review could provide further information about user experiences, especially how they are related to previous studies and product development challenges known to literature (Figure 1, “3.”). These three topics are studied separately during the research using appropriate tools for each. 1.4 Research scope Design thinking methodology will be used to approach the issue of improving the product design process. The selection of this particular methodology will allow us to make the problem more tangible from the start. The tangibility is achieved by focusing the research on solving the actual user pain points inside this system to improve the overall system. As 10 defined by the client, the example product development process starts when the development team have provided the first hours of work to the product development project. The process ends when the product is ready for batch production. That leads us to consider the interface between product development and manufacturing during the ramp-up of production as a part of the product development. The capability to order the first batch of products marks the end of the product development process. Adding to the complexity is also that while several companies have their product development operations, their main business area might be entirely different. There is an ongoing trend to change from product-focused company operations to service providers. This change in the business mindset can create more value for the customers and companies alike. However, it adds another layer of complexity to the product development process when the final product is only a part of a value-adding service and not the main focus. In this research, the service element is considered part of the input data at the start of the product development process and similarly adds more data requirements for the output of the process. Product portfolio management is yet another source of input data for the product development process. Because product development activities require large scale investments (Doorasamay, 2017) companies need to manage their potential product development initiatives. The main objective of this management is to find the ones that could yield the best return on investment. Product categorisation in technical and business portfolio terms is also handled as something included in the input/output requirements of the product development process. 1.5 Case example process Our case example provided a product development process that was managed by the phase- gate agile hybrid model. It meant that project (or process) milestone decisions and funding were managed by the phase-gates while the engineering level development work was managed by the agile sprint system (Chapter 2.3.2). The engineering level consisted of a multidisciplinary team of product development experts from all the relevant fields, including but not limited to mechanical engineering, electrical engineering, and industrial design. The concurrent engineering approach was the recommended method for advancing product development work made for the projects. This concurrent engineering included internal and 11 outside stakeholders alike. Outside stakeholders provided additional expertise for internal engineers for completing specific product development challenges. Having just completed a relatively large-scale project, the case example company saw an opportunity to improve the product development process ahead of the following major projects. Besides the engineering team, one outside stakeholder was of great interest to the company: the contract manufacturer produced the products for the company. This outside stakeholder was involved in parts of the product development process and provided their share of expertise for some selected concurrent engineering efforts. Continuous improvement is a necessary element of all product development operations. Previous improvement efforts were discussed during the meetings with the company to clarify where this research would begin concerning those previous development projects. The research goal was deliberately left open concerning where potential areas for improvement could be found. This goal suited the design thinking approach, emphasising exploration, defining problems worth solving and asking users for their input. 1.6 Literature review Introducing new products to the market and customers is a critical factor of success for any company. This continuous search for improvement is nothing new in product development. Focus on customers, and the need for constant innovation emerged from the work of the excellence movement that started during the early 1980s (Grieves, 2000). The newly explained focus of successful companies was further emphasized with the simultaneous rise of Just-In-Time (JIT) manufacturing (Reinersten, 1997). The modern way of operating product development as a project-based activity can be traced back to organizational development and manufacturing management movements. Furthermore, downsizing companies that started in the 1990s (Grieves, 2000) in the quest of the flexible firm gives another dimension to our equation. When companies create these flexible firms, they outsource operations that are considered not part of their core competencies. Division to the core and non-critical competencies meant that for process improvement, it is required to investigate a network of companies instead of only one 12 company. Companies need to give macro-level focus to their entire supply chain if they want to achieve sustainable competitive advantage (Green Jr., et al., 2014). Product development is considered one type of project activities companies tend to focus on their resources (Sauer et al. 2009). Using project models adds to the complexity of our issue because previous quantitative studies have shown that as many as thirty per cent of projects are cancelled before completion (Leach, 2000). The remaining seventy per cent are not all successes. They are more than likely overran their budget, time or delivered results different from what was first outlined. As Sauer et al. (2009) put it, “most projects do not meet time and budget goals or fail to satisfy customer and/or company expectations”. Research on the new product development (NPD) shows similarly narrow results. As Markovitch et al. (2015) describe, the high failure rate of products introduced to the market “remains one of the greatest challenges of new product research”. The most persistent improvement approach to processes to date is undoubtedly the Lean principles (Green Jr., et al., 2014). As Alves et al. (2019) state in their book Lean Engineering for Global Development, the term lean production (or management) can be found even from journals, the reader could not have predicted to find it. The Lean principles originate from the Toyota Production System (TPS), which was brought to the focal point of a global audience in 1990 with The Machine that Changed the World by Womack, Jones & Roos (Alves, et al., 2019). Womack and Jones later followed their earlier work by publishing the first edition of Lean thinking in 1996. In their 2003 second edition preface, they elaborate that “lean thinkers strive to reduce order-to-delivery-time”. Lean thinking means that production is done by “pulling” from the client just what the client is willing to pay (Alves, et al., 2019) and this way, eliminating wasted time otherwise used for producing features the client did not want. While the TPS was first used to produce cars more efficiently, it was also applied to the product development domain. Womack et al. (1990) define the lean system as one that also uses “half the engineering hours to develop a new product in a half the time”, an idea that is further elaborated in the more systematic approach to lean principles presented in the Lean thinking. Womack et al. original 1990 and the following 1996 Lean thinking book can be considered as examples of the literature aimed at the management in the genre of business novels. However, as Alves et al. (2019) put it, practitioners and the 13 academic community have contributed to the topic for the last 25 years, bringing the method and its abilities as a process improvement method to a level capable of withstanding scrutiny. However, the problem is not nearly as easy as just planning the implementation of lean principles. Grieves (2000) states that most improvement attempts fail, with success rates only reaching ten per cent in some industries. We can recall what Rittel & Webber (1973) argued about wicked problems to explain those numbers. They rationalize that in interconnected systems (our flexible company with supply chain and outsourced activities), where outputs become inputs to others, it is “less apparent where and how we should intervene even if we do happen to know what aims we seek”. Number five of the ten pointers that reveal if the problem is wicked one fits the product development. “Every solution to a wicked problem is a “one-shot operation”; because there is no opportunity to learn by trial- and-error, every attempt counts significantly”. Calling these wicked problems one-shot operations means that after the solution is done, it cannot be undone without at least some ramifications. In our case, if we choose a method and use it to improve the product development process, we at least have used some monetary resources we cannot get back by removing the implemented improvements. Another issue of failed improvement effort is the lack of communication during the change effort. Communication is a social process in which individuals can make sense together (Salem, 2006). Salem points out that “organizations fail to change when people believe they are not getting enough information about the changes”. Nevertheless, another critical issue on improvement programme failures is how they are executed from top to bottom. “The potential of the vast majority of problem-solvers in the firm is ignored” (McCarthy & Rich, 2004). Nielsen & Randall (2012) reports that they found support to the hypothesis that employee participation in the change process increased the implementation of the improvements. The wicked nature of the problem and findings of the failures of traditional improvement efforts support the decision to use design thinking to process development. Service design tools are described as suitable tools to “help deal with complexity and multiple stakeholders that are inherent in services” (Polaine, et al., 2013). Design thinking (and service design) is an interdisciplinary approach (Stickdorn & Schneider, 2011), (Costa, et al., 2018). It can be reasoned that since the product development process includes the combined input from several experts from various fields, it is appropriate to use a methodology that uses this 14 property of the problem as its strength. That strength is amplified by the other nature of this methodology: it is co-creative. “All stakeholders should be included in the service design process” (Stickdorn & Schneider, 2011). Sense-making, together with all the relevant stakeholders with tools capable of creating solutions to wicked problems, supports design thinking as a PD process development method. The application of this methodology starts by thinking about how we can integrate the stakeholders into designing it (Polaine, et al., 2013). Developing processes with this methodology does not mean leaving the lean principles out of the equation. The design process encircles around identifying what brings value and how to resolve user pain points. The idea is that removing user pain points can improve the overall user experience radically (Kraft, 2012), forms the basis of the hypothesis for this thesis work. The intent is to present the product development process as a service with a communicated value proposition that is perceived by the users. This value proposition is increased by removing any user pain points from the service (or PD process). Using the service, users create value as co-creators (Costa, et al., 2018). As an outcome of this value co-creation process, the company can extract value in product development process results while the users also receive value (job satisfaction). Employees also receive their share of the value company can create when they can successfully create new value propositions (products or services) aligned with the market demand and customer needs. 1.7 Design thinking “The outcome of a service design thinking process can have various forms”, explains Stickdorn & Schneider (2011). One of the outcomes they list is operational processes. This research is aligned with using the service design thinking tools to help achieve the research goals of improving the product development process. Service design thinking tools offer methods and approaches for all the different phases of the design process. The study on 11 companies conducted by Design Council identified that the design process could be visualized as a double diamond (Figure 2) (Childs, 2014). 15 Figure 2. Design process as a double diamond. (Design Council, 2015) The long horizontal arrow is our objective (in this case, improving the product development process). The design process starts from the discovery phase. The process first diverges from the straight path to exploring the topic and understanding and identifying user needs (Design Council, 2015). In defining phase, the objective is again brought to the attention, and the user needs, and other information is used to make sense of the possibilities they offer and present. Phase number three focuses on testing and refining the possible solutions. Finally, in phase four of the process, the focus turns to implementing the solution, evaluating it and ensuring proper feedback loops to collect relevant performance data. 1.7.1 Co-creation Co-creation is an essential part of design thinking methodology. It is used for “working collaboratively in order to examine and innovate a given service experience” (Stickdorn & Schneider, 2011). Stickdorn & Schneider describe co-creation as a principle that can be combined with all design thinking tools. Considering that design thinking is a multidisciplinary and user-centred process, co-creation is heavily encouraged for achieving results that align with user needs. Co-creation includes structured and open-ended elements. The Moderator role is essential in ensuring that given time is used towards broadly set goal while allowing all participants to collaborate and share ideas freely. The co-creation principle enables the use of organisational knowledge that is not present in management-led improvement efforts. As previously described, organisations problem-solving capacity will 16 create commitment from the employee side and ensure their user needs and pain points arise during the design thinking process and are addressed. Moderator uses presentation materials to open discussions and steer the conversation to a detailed level when an opportunity or otherwise interesting topic arises from the discussion. Documenting results of co-creation sessions is as essential as having good moderator skills. Design thinking sense-making efforts include many ways to visualise gathered knowledge and information. The core documentation tool used in this research is the service design tool “service blueprint” discussed in the following chapter. 1.7.2 Service blueprint To visualize the outcome of the design thinking process and to support discussion about the findings of this research service blueprint will be used (Figure 3). The service blueprint is “a visual schematic incorporating the perspectives of the user, the service provider and other relevant parties” (Stickdorn & Schneider, 2011). Figure 3. Service blueprint. These perspectives are visualized with a set of swimming lanes for each stakeholder (party). The blueprint covers the whole service lifecycle from the first action to the last action. 17 Service blueprint includes lines of interaction between stakeholders. Interaction can happen between any stakeholder. As can be seen, inspecting the arrows between different swim lanes in the Figure 3. Line of visibility is placed between the frontstage and the backstage on the service provider’s side. The user interacts directly with the frontstage leaving the backstage and support actions invisible to the user and thus the name line of visibility (to the user). Any service includes a set of physical evidence that supports the service flow or the service experience somehow. The service blueprint includes this evidence as an extra swim lane on top of the blueprint. In product development, this physical evidence might include product prototypes, important documents or any other physical objects that are important to include in the service blueprint. The blueprint's goal is to make all interactions visible and create a holistic view of the service experience for all stakeholders. 2 LITERATURE STUDY The first part of the information required for the chosen triangulation method is previous studies and literature. Studied literatures were terminology and methodology from three fields of study: product development, project management and design thinking. The literature study was done to understand how product development processes are being improved and what connections can be drawn between these different fields in the attempt to use those connections to present a framework for using design thinking as the primary tool for improving the product development process. 2.1 Product development process “Product development process is a sequence of steps that transform a set of inputs into a set of outputs” (Urlich & Eppinger, 2016). At the top level, product development starts from an idea of a product (Figure 4). The idea of a product is the input to the product development process. The input is transformed to the output (product based on the idea) that can be utilized by the company to create value for the customers and itself. 18 Figure 4. Product development top-level model. Going forward to explain what product development is, Urlich & Eppinger (2016) depicts it with six distinct phases (Figure 5). Each phase (List 1) of the product development has its own set of inputs and outputs. The initial input data to start the planning phase (first phase) is the idea of a product. The final output of the product development process from the production ramp-up phase (last phase) is the product itself. Furthermore, as the production ramp-up phase name suggests, the product development process ends when the product is ready to be utilized (or, in manufacturing terms, ready for production). Figure 5. Generic product design process (Urlich & Eppinger, 2016). List 1. Key elements in each product development phase (Urlich & Eppinger, 2016): Planning Design: consider product platform and architecture, assess new technologies. Manufacturing: identify production constraints, set supply chain strategy. Concept development Design: investigate the feasibility of product concepts, develop industrial design concepts. Manufacturing: estimate manufacturing cost, assess production feasibility. 19 System-level design Design: define major systems and interfaces, refine industrial design concept. Manufacturing: identify suppliers for critical components, perform make-buy analysis. Detail design Design: define part geometry, a complete industrial design concept with assigned materials. Manufacturing: define piece-part production processes, design, and purchase tooling. Testing and refinement Design: test performance, reliability, and durability. Implement design changes. Manufacturing: facilitate supplier ramp-up, refine fabrication and assembly processes. Production ramp-up Design: evaluate early production output. Manufacturing: begin the production. Urlich & Eppinger points out that each company has its own product development process that may vary even between different products inside the company. However, the general view of the product development process is transferrable between different product development-related processes investigated in this research: project management models and design thinking process. Further, in the results and discussion, a more detailed level analysis is provided. 2.1.1 Product data management An essential part of modern product development is different digital tools used to create and store product data called product data management (PDM) systems. They are software systems employing database structures to hold product data. This data is manipulated using PDM graphical user interfaces and software systems capable of creating new PDM data. These software systems include computer-aided design (CAD) systems used for creating 3D models representing the product geometry and other information relevant for manufacturing the product. The utilization of PDM systems varies from one company to another, and for 20 this fact, only the most basic data accessible through these systems are used for this research. These include information related to the product lifecycle state that can either be work in progress, released, or retired. Only information about the product documentation release dates is used in this research. PDM systems are also capable of managing engineering workflows and tasks. In this research, that information was available from another software. Agile management software used to manage product development process work was used as a source for information about work in progress inventory (or queue size). These two pieces of data provided by modern product data management related software are essential to verify literature and qualitative results obtained during this research. The same information is also available from other sources. However, the ability to obtain this data straight from databases makes the extraction, transformation, and analysis of this data manageable even with limited research resources. 2.2 Managing product development The input or the idea of a product can be identified as the starting point of the product development process. In a business setting, the input data can originate from several sources. Some organizations include natural channels for the data to flow towards product development. In contrast, other organizations might have built barriers to block that same data from reaching the parts of the organization where it might be used to start product development activities. Maintaining the data flow towards the product development is part of the product development operations. In reality, this means that relevant connections between other business operations and product development are in place. Usually, this means that the product development is organized as one of the business units. The same organizational structure applies to all business units, as shown in Figure 6. 21 Figure 6. Matrix organization (Stuckenbruck, 1979, modified by author). Matrix organization is one example of how a company organization is structured. It is possible to inspect how the data flow reaches the product development unit using the Figure 5 matrix organization. In this example, product development serves all the company’s product development needs. It is connected to other business units that can be visualized as a matrix, thus the name matrix organization. Data flows through the connections in this matrix: product development receives data from different product units A and B, research unit, marketing unit and sales unit. An example of data that product development receives from the sales unit might be customer feedback, financial reports on product sales performance or a product opportunity sales unit has identified in comparison to competitor’s product offerings. Similarly, the research unit might provide new data regarding the technologies currently used in products A or B that might trigger product development activities like updating the products with new technology. This data flow enabled by the matrix organization differs in many ways compared with another organizational model called divisional structure (Figure 7). 22 Figure 7. Divisional organization. The number of different ways companies organize is vast, but the purposes of this thesis comparison between matrix and divisional organization are enough. Looking at Figure 7, it is clear there are some significant changes compared to the matrix organization. Focusing on the data flow, it is evident that product units (or divisions) work independently from each other in this structure. The product development unit receives data relevant for its home division, but not the other divisions' product development units' data. Organizational structures differ from one company to another, and generalizations about their positive and negative effects are nearly impossible to make. However, it is essential to notice that product development operations depend on the company structure regarding the input data that product development receives. Input data affect what products are being developed and what decisions are made during the product development process. These factors are essential when inspecting our case company to find how the product development process could be improved. While consequential phases sometimes describe the start and the end of the product development process, there is a need to dive deeper into the actions that happen before, during and after the product development process for being able to improve it. Taking the top-level model (Figure 4) to a business environment, we immediately see some added complexity. Decision making (Figure 8) plays a vital role in product development. 23 Businesses have finite resources, and the decisions to either develop or discard products must be made with care. This decision starts the product development process at the top level and eventually ends it when specific criteria are met. In a successful product development process, the original idea of a product is realized, and the final product is ready for utilization. Companies rely on either project management or portfolio management when making product development-related decisions. In the product portfolio management, the “list of active new products and R&D projects are constantly revised” (Doorasamay, 2017) concerning company strategy and operative goals. On the other hand, project management is used for managing active projects according to the set of goals given to that specific project. Figure 8. Decisions added to high-level model. Decision-making includes a transfer of information used to decide to start the product development process and information about the product itself. These two pieces of information can be seen as the input data for product development (Figure 9). After receiving this input, product development operations are aligned so that the expected outcome or output data can be obtained during the product development phase. Final output data includes the information about the product and how to utilize it for the purpose that was seen as valuable when the decision to start the product development was made. 24 Figure 9. Product development input/output model. 2.3 Concurrent engineering Concurrent engineering is the essential concept currently available when product development improvements are discussed. Many methods rely on improving product development by introducing elements similar to concurrent engineering (CE). One of these is the Agile development method Scrum (chapter 2.3.2). In concurrent engineering, the goal is to involve a multidisciplinary team of expert to work on a development problem starting from the beginning of the project. The concurrent start of the development work contrasts with the traditional way of doing development projects where development work moves from the desk of one expert to the next one without any concurrency in the tasks. 2.3.1 Project management methods To manage the transfer of information related to the idea and develop it to product, companies rely on project management methods (Sommer, 2015, Doorasamay, 2017). Project management is a convenient way for a company to manage the path from idea to a product in one manageable unit called a project. There are various ways these projects flow from start to finish - “no single type of life cycle is perfect for all projects” (PMI, 2019). Project Management Institute provides a framework for differentiating between those different models by the projects two characteristics, frequency of delivery and degree of change (Figure 10). 25 Figure 10. Life-cycle continuum (PMI, 2019, modified by author). The first model is predictive (Figure 11). It is used in projects for products that are well defined even before the project starts allowing the project team to plan scheduled events beforehand. The project execution is just a matter of following the pre-determined path from start to end because the degree of changes is low. (PMI, 2019) Figure 11. Predictive project. The second model (Figure 12) includes explicit feedback loops for improving the features before entering the next phase. (PMI, 2019) Figure 12. Iterative project. 26 The third model (Figure 13) provides the client or the customer with deliverables early in the project. This model has had much interest since it describes the process of creating value for the customer as early as possible (PMI, 2019), as the Lean principles teach us. Figure 13. Incremental project. The last model has had much interest similarly towards it. The first difference between incremental and adaptive is the rate of change (PMI, 2019). They could be distinguished by thinking about the content of the project. If the product development work is only done to change some current product offering incrementally, the incremental project model could prove the correct answer. However, suppose the goal of the product development project is to enter new markets and find innovative solutions for totally new product offerings. In that case, the adaptive project model (Figure 14) should be investigated as the right choice. The second difference between incremental and adaptive models is the delivery. In the incremental model, the product is designed in smaller modules delivered to the client when ready. After one module is ready, the project moves to the development of the next one. In the adaptive model, delivery is continuous. With testing and writing new product requirements based on the test results, the project approaches the delivery ready state of the product with each cycle. This model can be used with fixed cycle times or with flexible ones (PMI, 2019). 27 Figure 14. Adaptive project (PMI, 2019), Modified by author. These four project models enable us to investigate the case study project model and identify the used project models. Such commercialized methods as Scrum or Stage-Gate can be identified to follow certain features described in the above models. 2.3.2 Project management in businesses Businesses seek repeatable processes with good success rates in achieving their goals (project output data). They have standardized their project management models to support this goal. The use of project management methods has led to creating a project management industry with commercialized methods and tools for managing projects. Following the information about the case study, an investigation of two commonly used project management methods (or tools) is conducted. These are the phase-gate project method and agile project management tool Scrum. Phase-gate project model Depending on the reviewed literature, the phase-gate project management method originated from the US Navy project Polaris and the invention of the Program Evaluation Review Technique (PERT)-model, or it was a brainchild of Robert G. Cooper. Following his research on why companies were successful or failed at new product development, Cooper created a Stage-Gate project model. It is also linked to the Critical Path Method (CPM). As George Ellis (2016) describes in his book, Project management for product development, phase-gate model, and CPM together “form what is most certainly the most popular method for developing hardware products”. As its name suggests, the typical characteristics of a 28 phase-gate model are the division of the project into distinct phases. Commonly, the company forces all projects to follow the same phases. Different companies have different project models that suit their needs, but commonly there are around six phases (Ellis, 2016). Figure 15 depicts the phase-gate project model. Noticeable similarities with the generic product development process (Figure 5) introduced in the previous chapter can be seen. Figure 15. Phase-gate project model (Ellis, 2016, modified by author). Gates one to six represent decision milestones. They are placed on reviewing the work done during the phase, and based on project requirements; the project can move to the next phase, stay in the same phase, or be stopped and dissolved from using any more company resources. As previously mentioned, these gates ensure that the company’s finite resources are allocated to the most promising projects and killing of the poor performing ones that only consume those resources without signs of return on investment. Agile project model It is common to compare Agile methods to phase-gate because they represent the opposite ends of the project model spectrum. Scrum is an Agile project model (Figure 16) that was first presented by Takeuchi & Nonaka (1986). They too present it as an alternative to the “old approach” that “went sequentially from phase to phase”. 29 Figure 16. Phase-gate model versus Scrum model (Takeuchi & Nonaka, 1986). This first visualization of Scrum is nowadays transformed to what we learned about adaptive project models. Today there are no more distinct phases in Scrum but only development cycles that go through all the phases from one to six in each cycle. Table 1 describes what characteristics enable this repeat of Agile cycles (or sprints) in the project. Noticeable differences are the lack of control that the phase-gate model offers with phase-gates as decision points. The scrum method hands the control to the team. Management provides a challenging timeframe and enough funding to allow the team to realize the project goal. The presence of ambiguity and uncertainty in the Agile methods, as seen from the perspective of the company’s decision-makers, have created new project models that combine these two rivalling project management models into one hybrid model. Table 1. Scrum characteristics. (Takeuchi & Nonaka, 1986) Built-in instability. Great freedom to carry out project. Self-organizing project teams. Project team operates as a start-up company. Overlapping development phases. Knowledge sharing between team. “Multilearning”. Continuous testing. Subtle control. Established checkpoints. Organizational transfer of learning. Converting best practices to standards. 30 Modern Scrum tools are software-based platforms that allow users to organize tasks per their role in the project. Self-organizing teams can plan their sprints, and individual experts can manage their workflow inside those sprints. Project management can access project backlogs and prioritize development work that teams can choose to work on during the sprints. Modern Agile tools are divided into multiple different terms, but the nature of splitting larger work packages is present in all of them. One additional term to mention is Kanban that sometimes is used interchangeably with Scrum (PMI, 2019). Kanban is a sub-system of TPS (Lage Jr. & Filho, 2010) and a part of the Lean principles. An example of a modern software- based Kanban system is explained in figure 17. PMI (2019) argues that the difference between modern Scrum and Kanban is that Scrum is used to divide the project goal into user stories. Kanban is limiting the number of tasks in different states of development (queue, work-in-progress). Furthermore, user stories in Scrum are how the development team has the voice of the customer always present during the development work. Figure 17. Kanban-board. As noted before, companies modify these methods to suit their needs. The case study company uses the combination of Scrum and Kanban, where user stories are the largest units on the project backlog consisting of a variable about of work packages that are again split into work packages. The Kanban method comes to play when engineering teams select work to develop in their schedules (or sprints in Agile terms), limiting the number of tasks allowed in the system. 31 Agile Phase-gate hybrid project model Project models are placed in operation to ensure that resources are used when and where needed and ensure that the product development efforts are aligned with the overall corporate strategy. The blend of strategic and operational decisions has led to Agile Phase-gate project model hybrids that offer strategic level decision making on the top and fast-paced product development teams at the operational level of the company. The development in this direction is also answering to the “decrease of product life cycles combined with growing customer demands (Sommer, et al., 2013). Another driver is that software companies who first combined these two project models already had enjoyed the benefits of Agile that are widely studied and documented (Cooper & Sommer, 2018). The results from the software industry gained well-deserved attention from manufacturers of hardware and physical products. Cooper (2016) reports that when a manufacturing company started to use an agile phase-gate hybrid model to speed up development, they witnessed a speed increase of around thirty per cent, as a consultant Lars Cederblad explains to Cooper (2016). When Sommer et al. (2013) interviewed three manufacturing companies, they reported three different project model hybrids. The finding follows the understanding that different companies modify their project models based on their own needs. Based on the information about this thesis works case example company’s product development process, only the hybrid model one similar to it is presented (Figure 18). Figure 18. Agile-phase-gate hybrid project model. (Sommer, et al., 2013), modified by author. 32 In this hybrid model, the phase-gate project model offers control and funding mechanisms to projects. Project Scrum level manages the project goals and ensures that self-organizing Scrum teams deliver development work to ensure passage through phase gates (Sommer, et al., 2013). Like Scrum, this method requires engineering teams to self-organize on the Team Scrum level to ensure that the project will enjoy the benefits Agile has to offer. When the project progresses through a phase gate, a new phase in the project starts. In the engineering team level of the project where the Scrum model is more closely followed, the phase gate might align with the completion of Scrum activities, or it might not. Scrum level activities allow iterative cycles by design in the development process while phase gates advance the delivery. With this structure, the company seeks to operate the product development as a repeatable process with predictable output and managed success rate. While successful product development itself is a challenging task (Markovitch, et al., 2015), adding multi-layered project management to the issue makes it even more challenging to improve (Sauser, et al., 2007). Focusing on a product development process that aims to develop products ready for batch production helps us identify more improvement opportunities rather than limit the number of areas where improvements can be made. 2.3.3 Managing performance Project management models are placed to control issues that arise from factors like queues and batch sizes. There is a theoretical background for why some project models aim to limit the amount of work inside the product development system and why feedback loops are of great importance to product development processes. According to Reinertsen (1997), there are four main genres of control measures we can utilize to keep the performance of the product development process at wanted level (and improve it): 1. Increase capacity 2. Manage demand 3. Reduce variability 4. User control systems Capacity is critical because product development as a system overloads before reaching a 100 per cent utilization rate (Reinersten, 1997). This can be explained by mathematical 33 model part of the queueing theory, Markovian arrival process. Examining a queueing in a M/M/1/ ∞ system (Figure 19) it has been noticed that the queue behavior is non-linear. If the capacity utilization is moved from 80 to 90 percent the relative time in the queue doubles (Reinersten, 1997). A multi-variable case study conducted by Beauregard et al. (2017) points to similar results that engineering resources working in an environment where multitasking is present the maximum capacity utilization is 75 percent and similarly the optimum capacity utilization was less than 75 percent. Answer to the multitasking dimension was that the optimum number of concurrent tasks is less than two (Beauregard, et al., 2017). Figure 19. Capacity utilization (Reinersten, 1997), modified by author. Improving the product development process by changing the capacity is offered as one solution. In the modern business environment, outsourced resources that are readily available can be helpful. Reinertsen (1997), however, noted that outsourced resources have a learning curve and warm-up period that is observed to happen in projects (chapter 2.3.4), meaning that the outsourced resources should be fed a steady stream of work to keep them familiar with the project goals and progression and this way increase their usefulness when capacity utilisation of the project resources demands an increase in resources to handle delays related to capacity utilisation or queues. Following organisation development trends where organisations are viewed as knowledge-based systems, increased productivity has also been seen as an option to increase capacity. If a knowledge-based organisation increases employees’ productivity, it simultaneously increases the organisations capacity to process knowledge (Grieves, 2000). Of course, the interest of this approach has to do with the fact that an increase in productivity does not raise the cost of labour since a capacity increase can 34 be found in the current engineering workforce. The management approach to increased productivity has introduced a concept of Managers as Coaches (MAC). Research points to the direction that coaching can increase employee productivity, but the coaching approach required from managers needs rigorous training (Ladyshewsky, 2010). The conclusion from this concerning engineering productivity would point to the direction that training the engineering workforce itself. Reinertsen (1997) lists training alongside better tools, increased support and reduced value-added activities. The reduction of value-added activities was also considered by Beauregard et al. (2017) in their literature review when they found out that “beyond a certain level of multitasking, a declining project completion rate and associated revenue generation occurred”. Again, by reducing the number of tasks per engineer, productivity can be increased without increasing costs. The balance between cost of labour and investment in better tools was discussed by Reinertsen (1997), pointing out that investment in better tools like CAD-software “almost never costs as much as people” while improving the productivity of current engineers. In the engineering team’s ability to manage demand, reuse presents itself as a capable tool because it simultaneously reduces variability when discussing the duration that the development of a new product or feature takes. Reuse is a shortcut since the product feature is already available, and thus variability is reduced to the minimum. To manage the demand for new work, solutions like the Agile methods described previously have proved useful. This links to the Lean principles and the principle of reducing inventory size and changing the direction to pull - demand is not pushing new development work into the product development process. However, the free capacity is instead pulling new development tasks into the process when previous tasks are completed. Reducing variability is an issue consisting of three main methods, reducing batch sizes, concurrent engineering, and creating a closed-loop system by adding feedback loops to the product development process. Concurrent or overlapping project is a similar method proved by the Scrum and Agile methods (Figure 20). By organizing the engineering as a self- organizing team that works to solve a bigger problem, the process moves from sequential phased project to overlapping project model to decrease the process development lead time. This reduced lead time is explained more clearly by the differences in variability between these two models (Figure 21). In the sequential phase-gate project, the total variability σ 35 would be the square root of the sums of the squares of each phase. In contrast, the total variability of the overlapping project is determined only by the worst-performing phase. Figure 20. Concurrent engineering project (Reinersten, 1997). Figure 21. Variability in project. The difference in variabilities is an important observation because the product development process is a one-time process where individual tasks may occur only once, increasing the variability of the task duration. When we use a concurrent engineering process, we reduce this variability because, in contrast to the phase-gate model, individual phases are no longer affecting each other. The issue of batch sizes and feedback is. As proposed earlier, the 36 product development process is a process of inputs and outputs. To create the correct set of new information in the least amount of time, adding feedback to the system and simultaneously reducing batch sizes to allow this feedback to enter the product development process earlier are a winning combination. Another aspect to this is the probability of creating that correct set of new information required to create the new product (output data) that happens when the probability of failure (or error) is fifty per cent. Suppose a batch of work is a measure of work accumulated over a period. Combined that fifty per cent of the probability of failure for the maximised creation of information can be achieved, we can see that we simultaneously accumulate errors (Figure 22). By accumulating many errors, we increase the amount of rework because we do not know about these errors for a long time. Suppose small batches are instead used to create the information. In that case, we can reduce the number of errors we accumulate and similarly respond to them faster when we receive the information earlier. Figure 22. Batch size and feedback. (Reinersten, 1997) In product development, this early arrival of information is essential because features inside the product are linked together in a system of interfaces (Reinersten, 1997). When we get feedback about the changes early, we can implement a fix or a revised solution before the system gets too complicated and when the cost of change is risen too much to bear for the project. “Changes that occur late in the development of a product affectedly involve changing more product documentation and artifacts” (Folkestad & Johnson, 2001). The 37 rising amount of rework means that non-recurring items in the balance sheet start to appear when a product development project progresses. These include tooling, certifications, packaging design and manufacturing, and other overhead costs the organization needs to handle to communicate the product design to other stakeholders. This product development reality has led to the finding that cost associated with changes in product development rises rapidly (Folkestad & Johnson, 2001). Reinertsen (1997) describes the nature of this change as an exponential one. 2.3.4 Measuring project performance The mentioned feedback loops help product development project manage the demand and monitor the creation of the output data. They also reduce the need for strict design processes or rules because the feedback of the output data itself reveal the status of the product development system. Reinertsen (1997) proposes the definition of a product development process as a closed-loop system. Suppose we return to the idea of product development as a process where inputs are used to create a set of outputs. In that case, the feedback loop inside the development process will describe a data flow from the output to the development of that output data. This is achieved by using small batch sizes that can be tested early, thus creating information about the output data before we even have the complete output data ready. This information about the outcome before it is completed has two main implications (Reinersten, 1997). First, we can use the finite product development resources where they are needed most when the feedback loop is in place to tell us when the batch of work has received its goals as a part of the final output data. Second, it is an essential enabler of the Lean principles and the pull system. We can use the management resources to improve the quality of the pulled information that helps us create the right set of output data rather than focusing all our efforts on designing the product development process. Considering the rate of change in modern organisations, the investment in quality feedback loops (Figure 23) can improve the longer-term product development process. When implemented wisely, they can withstand the organisation's changes to create the output data (product development organisation) separately from the organisational changes. 38 Figure 23. Feedback loop. While the work that arrives in the product development system describes the change of the size of the queue in the system, the accumulation of the completed work can tell us more about the state of the project. The productivity graph collected by Mochida (2013) follows closely normal distribution (Figure 24). Reasons for this are that there is a “paucity of detailed information necessary for completing the work” (Mochida, 2013). In other terms, the project is first winding up and slowly starts to generate more information about the product development work ahead. The lowering slope at the end is a signal that most of the tasks and resources are used, and the project is near its finish line. Figure 24. Productivity (Mochida, 2013). This representation of accumulated items within time in projects is called the s-curve. In project management literature, it is described only by its characteristics (Cioffi, 2005). If we wanted to build an s-curve mathematically, we would assume that the accumulation follows closely normal distribution (Figure 25). 39 Figure 25. Task distribution S-curve. The s-curve can be used to inspect the product development process flow. It can be assumed to follow this s-shape, and any deviations from this shape would point us to investigate that time more closely. In the case of work in progress arrivals, the curve tells us at what rate the project produces new tasks. Suppose the slope of the curve changes dramatically. In that case, we can assume that the system is either overloaded and queues are present in the system or that the system uses large batch sizes that result in long feedback loops while the progress of the project may elongate. 2.4 Process development with design thinking previously brought to our knowledge, improvement attempts related to product development have been primarily focused on management-led change efforts. Efforts to implement lean principles have been plenty. Lean principles try to change manufacturing from pushing products to the market to pull. New products are only developed when customers want them, reducing inventory and waste. Following the Lean principles, the change effort can be changed from being pushed to the employees to pull from the employees. The co-creation with employees is where the design thinking approach differs from the traditional process development approaches. It starts from the other direction as a user-centred process, not different from how the Lean principles are meant to be implemented. Design thinking is a more extensive definition for a set of methods to approach problems and development challenges from a unique direction (Clarke, 2020). When we want to implement design thinking to process development, we must use design thinking methods to deal with designing intangible objects of study. These methods mean focusing on a set of tools that are described as service design tools. 40 Lean principles are a framework of changing ways of doing rather than focusing on qualities of the outcome as a result, and so is service design. “Approach of service design refers to the process of designing rather than to its outcome” (Stickdorn & Schneider, 2011). This focus on the process rather than the outcome is the differentiating factor compared to design thinking tools focused on designing and creating products. In line with the definition, this research is focused on explaining the service design thinking process itself rather than the outcome of the process. 3 PROCESS DATA The second part of the data required for the triangulation was available case study process data. Two datasets were obtained for the research. Frequency of completed work inspected one selected product development project. The development work rate was studied and analysed using literature-based methods(Cioffi, 2005) and later using the triangulation method. 3.1 Frequency of completed work Completed work examines the release of finished product documents, not the completion of individual project tasks. Product data management software was used to extract completion dates of 505 product documents released during the product development project. The product documents can be categorised as a collection of CAD files, including 3D models of discrete parts, assemblies containing more than one part from the first category and 2D drawings. After the extraction process, they were prepared for analysis using a histogram. Histogram bin size was determined as a 15-day duration. This gave a total of 49 bins for the whole duration of the product development process. The 15-day duration was used to reflect the two-week sprint cycle used in the product development process. Data were analysed to form results and connections between the results from the design thinking process discussed. 3.2 Frequency of work in progress arrivals Work in progress (WIP) arrivals were mapped using a histogram. Exact bin sizes and the number of bins was used with WIP and completed work (previous chapter). WIP depicts the 41 arrival rate of new tasks into the product development project. The objective was to determine project flow from start to finish from inspecting the s-curve created with the WIP data. Data was used to confirm and support findings from the design thinking process. The data includes all assigned tasks and completed by the engineering team to finish the product development of the example project. 4 DESIGN THINKING APPROACH The last part of the data needed for the triangulation involved the main interest of the research or design thinking. Design thinking methods were used in obtaining the data. An iterative process was used when selecting the consecutive design thinking tools. Based on the results obtained by the previously selected tool (for example, the first part of the theme interviews), the method was refined for the next one (second part of the theme interviews). 4.1 Design thinking co-creation methods The scope of the research can be described as a design thinking process that uses services design tools and covers the first diamond, or phases one and two (Figure 26). Tools for discovering possibilities and user needs are used following sense-making, where all the gathered information is brought together. The work concludes by offering directions for developing and delivering the change and discussing how the change can be measured using the same tools used in the discovery and define phases. 42 Figure 26. Applied design thinking approach. The agile development method was used as a tool for the design thinking approach application. Agile sprints with a two-week duration were used to plan, execute, and evaluate design thinking process progress. Results and feedback about the sprint activities affected the activities of the following sprint. The Agile method proved to be successful when communicating with different stakeholders and finding optimal ways to co-create new ideas and possible solutions as a part of the design thinking process. 4.1.1 User of the product development process The engineering team was selected as the user of the product development process. The decision was made to visualize the interaction between the engineering team and the contract manufacturer. When the engineering team was selected as the “main user” of this process (or later, a service), I was able to depict this interaction as a service blueprint. This suited the purposes well because now the research had a way to describe product development process interactions as they happened in relation to time. 4.1.2 Product development process as a service In service design and development, we are interested in the quality of interactions and the length of time our user spends in the service – the same essential factors we are interested in when improving the product development process. Services are described as combination 43 events that happen in time – similarly as we describe processes. Inside the service, there is various physical evidence of otherwise intangible service. In the case study product development process, that physical evidence was defined as different versions of the product under development from mock-up phase to prototype, and finally to the production-ready product. Production-ready production as a description is similar to “product ready for utilization” and means that it is the outcome (or output data) of the product development process. 4.1.3 Theme interviews Theme interview was selected as the first co-creation method to be used. The most important stakeholders were selected for discussions about the research topic. Two themes were discussed during the research. First was the known challenges and possible areas of improvement of the product development process. The second theme was digitalization, including possibilities of implementing better tools to the product development process as a possible solution to the research problem. The promise of digital tools as an answer to found user pain points was also discussed when the design thinking process was started, and follow-up discussions held with stakeholders responsible for digital tools used in the case example company. 4.1.4 Known challenges and possible areas of improvement Literature review combined with a list of generic problems present in product development organizations provided by Kennedy (2003) was used as a basis for discussions about known challenges and possible areas of improvement. Kennedy’s 2003 book on Lean enterprise provides novelized version about tackling product development challenges. It, however, provided a valuable list of generic challenges that were easy to communicate to different stakeholders in a concise and understandable language. The objective of these interviews was to modify the baseline assessment (Table 2) to reflect the actual situation. The second objective was to list past improvement efforts or projects and to have a retrospective discussion about their estimated impact on the identified challenges. Stakeholders involved in this part of the theme interview were members of the product development operations of the case company. Their roles included the development work manager of the engineering 44 team, product development design manager, and engineering team, including mechanical and electrical engineers, manufacturing technicians, and industrial designers. Table 2. Baseline assessment (Kennedy, 2003). 1.Administrative leadership 2.Low value-added effort 3.Ineffective design reviews 4.Pseudo concurrent engineering 5.Minimal learning between projects 6.Low engineering experience 7.Inaccurate scheduling 8.Long design loop backs 4.1.5 Digitalization The high level of digital product development tools in the case study company offered an exciting and timely discussion topic for the second theme interviews. Based on the literature review, questions about modern digital product development tools were listed and used as conversation openers in the discussions held between case study company representatives and their software vendor (Table 3). The case company management and software vendor technical experts, and key account manager were involved in the interview. Table 3. Literature review-based conversation topics. Internet of Things (IoT) enabled feedback loops Fleet management software as a feedback channel to product development Application programming interfaces (API) from PDM to ERP etc. Automated product documentation quality assurance tools PDM data extraction for research purposes 4.1.6 Questionnaire The theme interviews revealed an updated version about known challenges that were done to improve the product development process. As a warm-up assignment to workshops held 45 during the design thinking process, a questionnaire was used. The questionnaire was designed for the engineering team, and it contained ten questions (Table 4). Each question explained one known product development challenge. According to their opinion on how they solved the challenge in question, users were asked to rate between one and five the previous improvement efforts (Table 5) according to their opinion on how they solved the challenge. Answering one would indicate that the participant thought the development project was making the situation worse while rating it with five meant that they felt it solved the challenge. The last question was reserved for user input regarding any other known challenges that were not discovered or identified during the theme interviews as the participants differed by a degree. The questionnaire was presented for the whole engineering team, including mechanical and electrical engineers, industrial designers, and management, in a total of nine people. Table 4. Questionnaire content. 1.Administrative project management 2.Amount of non-project related meetings 3.Project reviews 4.Concurrent engineering 5.Competence/specialization 6.Quality and selection criteria 7.From development to production 8.Learning between projects 9.Long feedback loops between iterations 10.Other challenges/solutions Some management level challenges were translated to more user-friendly questions. One example would be Question 2 in Table 4. Challenge about the engineering resources value- added time versus administrative tasks was translated to the number of non-project related meetings and company sessions they must participate in during the work hours. 46 Table 5. List of past improvement efforts. 1.Agile sprint system 2.CAD/CAM competence development 3.Design documentation 4.Use of outside experts (consultants) 4.1.7 Workshop Two workshops were held for the whole engineering team. These two workshops covered introduction to the research topic followed by the list of topics divided to two separate workshops: 1) Questionnaire follow-up co-creation session 2) How to identify a good project 3) Different levels of improvement 4) Service blueprint Three workshops were held for a larger set of stakeholders. The first workshop was smaller and included four participants from the case company and manufacturing partners organization. The second workshop included previous participants and a procurement expert from the case company accompanied by a sales representative from the manufacturing partners organization. The third workshop added the following participants to the previous: experts responsible for the development of automation and IT architecture of the manufacturing partner. These workshops' objective was to create a service blueprint that accurately reflected the current state of the product development process. All stakeholders that were depicted in the blueprint were involved in these co-creation sessions. A draft version of the service blueprint was used as a conversation starter, and each session advanced the blueprint. After each session evaluation of the blueprint was held. The evaluation was used to reveal any need to invite more stakeholders to complete the blueprint. An additional session between all stakeholders was used as the last step to introduce the final version of the service blueprint and offer all participants the opportunity to give feedback or question any blueprint elements. 47 4.1.8 Service blueprint During the workshops, the service blueprint was used as a tool for discussing the process, and at the same time, it was a documentation tool. At the start of every co-creation session, the most recent version of the service blueprint was shown, and during the sessions, it would evolve based on the discussion and group decisions about the process steps and how they are aligned with each other. Final approval of the service blueprint was received by introducing it to all stakeholders. Three key results were achieved by this one tool: 1) mapping user pain points in current process 2) co-creating new ideas and potential solutions 3) visualizing the current process 5 RESULTS & DISCUSSION Results from the literature study, process data and design thinking approach were examined separately, and after this, the triangulation between them was conducted to increase the credibility of each (Figure 27, 1,2,3). Figure 27. Used triangulation framework. 48 First, understanding about the current state was acquired and the user of our process defined. Second, the process was defined to enable design tools when discussing it with our users. Third, relevant data were extracted and transformed into a form that could better understand the process. After these steps, users were involved, and various design thinking methods were used to discuss the process, map current user pain points, and co-create possible solutions. Theory and current studies referenced in the previous chapters gave weight to some solutions while users could bring more emphasis to others. In best cases, there was theory and previous findings to point in the right direction, data to show where the process was, and users who could elaborate their experiences and share ideas about the correct way forward. 5.1 Design thinking approach The first results obtained with the design thinking approach considered the baseline of the current product development process. During interviews, a more in-depth view of the process was formed, and a refined list of known challenges generated. Because of the nature of the design thinking process as a user-centred approach, these results were not valuable for the research before discussing with the users. This was completed by conducting the questionnaire and discussing the results during the workshops held for the engineering team. The literature-based list of generic challenges contained eight items. Items 9 to 11 in Table 7 were added based on the theme interviews. It was found out that one challenge was the high level of individual specialisation considering engineering tasks. This created a possible issue because engineering tasks could only be assigned to a limited number of resources without backup if that resource were overloaded or not available. Cross-trained engineering workforce was offered as a solution to increase productivity by Reinertsen (1997). This way, other team members could be used as a backup when demand exceeds the engineering team’s capacity to process the work. The quality and selection criteria of the product development work were found as a second item that was added to the original list. This meant that based on the feedback from manufacturing quality and selection criteria could have been used to improve quality aspects if they were provided. Since they were not communicated clearly during the design phase, they did not transfer to the manufacturing. This discussion led to the last added item, outsourced manufacturing. Outsourced activities require interfaces between two organisations. Based 49 on the literature, interfaces in any system tend to offer the most amount of improvement possibilities because the most value is created through them. This finding finally confirmed that the service blueprint should be useful in investigating this product development process and that the correct interface to inspect was the interaction between product development and manufacturing organisations. After the first theme interviews, the second theme interviews were held to study better digital tools. Table 7. Theme interview results (first theme) 1.Administrative project management 2.Value-adding time 3.Project reviews 4.Concurrent engineering 5.Learning between projects 6.Engineering competence 7.Scheduling is challenging 8.Long feedback loops 9.Areas of expertise 10.Quality and selection criteria 11.Outsourced manufacturing Constantly evolving digital tools to increase productivity had emerged as a possible area to investigate during the first part of theme interviews. This led to the second part of the theme interviews that were held between the company and the CAD software vendor. Product development companies have usually selected one CAD software to use for their product development, and this case was not different. Because investments in CAD software are long term, it was reasonable to limit the discussion to new features added to the existing CAD software but not yet fully utilized in the company workflow. The interview revealed that there was indeed an application built to improve the user-friendliness of the company’s current PDM software that was not currently in use. In a follow-up interview, this application was discussed more in detail, and it revealed much potential for solving user pain points found in the second set of workshops that included stakeholders from the two organizations. 50 The nature of this as a possible solution is discussed further down in this chapter when the service blueprint is discussed and in the list of results at the end of this chapter. As previously mentioned, the theme interview offered a list of challenges that could be further investigated. This was done by conducting a questionnaire where participants represented the engineering team (user of the product development process). Results from this questionnaire pointed to the direction that previous improvement efforts were addressing the known challenges with positive effects. Strict screening of results was used to reveal possibly solved challenges. Table 8 highlights solution/challenge combinations with a score of 4.0 or above. Improved design documentation considering design choices made during the projects was the best performing solution, but after limiting its impact by screening only challenges where it scored 4.0 or above, the results were more evenly distributed between the first, second and third solution. Interestingly, solution number four or “use of outside experts” did not achieve scores above 3.7, leaving it completely off as a solution after the screening was applied. During the follow- up discussion about the results, the reason has revealed. The engineering team experienced poor performance and results when outside experts were used to even the workload during the case example product development process. The mentioned outside experts were used to design relatively large subassembly as a one-off assignment. This result was explainable by the literature: if good performance was to be expected from outside resources, they should have been primed to the project by assigning them tasks in a steady stream. Assigning only a one-time, relatively large batch size subassembly contradicts this literature finding. 51 Table 8. Questionnaire results (known challenges). Challenge: Solution: 1 2 3 4 5 6 7 8 9 1 4 3,7 3,5 3,7 3,2 3,7 3,4 2,6 4,1 2 3,4 3 3,2 3,7 4,5 3,4 4,2 3,5 3,2 3 4,2 3,8 3,9 3,8 3,8 3,9 3,9 4,3 3,8 4 2,6 2,6 2,5 3 3,7 3,1 3 2,6 2,9 List of solutions: 1.Agile sprint system 2.CAD/CAM competence development 3.Design documentation 4.Use of outside experts (consultants) List of challenges: 1.Administrative project management 2.Amount of non-project related meetings 3.Project reviews 4.Concurrent engineering 5.Competence/specialization 6.Quality and selection criteria 7.From development to production 8.Learning between projects 9.Long feedback loops between iterations While consultants were not a clear solution to any of these challenges, four out of nine challenges did was left without a good solution completely. Amount of non-project related meetings, issues with project reviews, concurrent engineering or quality and selection criteria were challenges still looking for good solutions. Question number 10 was open- ended and user input was needed to complete the questionnaire. This question was not mandatory but regardless of that resulted in a list of nine additional challenges (Table 9). While users were asked to also list solutions to these none was given. Literature provided answers to most of the new challenges. Uneven workload distribution during the project is linked to the large batch sizes that eventually increase variability and following that can lead to large queues when feedback eventually loops back. In addition to small batch sizes concurrent engineering was offered by literature as an answer. When work on different product areas is started simultaneously utilization rate is higher from the start and previously consequential tasks can be started earlier with better productivity because project goals are already communicated to all team members. The ability to start the work earlier results from 52 the smaller batch sizes throughout the product development process. Smaller batches move forward in the product development process reducing the queues and waiting times. This affects the project economics when resources are not idling, improving the lead time and the return on investment. Milestone decisions stalling the project is another issue that was solved by the literature review for the research. Large milestones were linked to large batch sizes and again larger queues and longer feedback loops. This finding is further investigated when case example project data is presented further in this chapter. Table 9. Questionnaire results (new challenges). 1.Workload distribution during projects 2.Milestone decisions are stalling project 3.Original schedule does not change even if project scope changes 4.Number of changes between production batches 5.Re-use of components is low between projects 6.Organization silos prevent efficient use of resources 7.Agile sprint goals are vague 8.Design freeze points are not communicated enough 9.Making price estimations during design phase is challenging The concrete result from workshops held during the research was the service blueprint (Figure 28). By visualizing the product development process, all stakeholders could picture the interactions inside the system. The objective of this research was to improve the product development process. As such, the visualization of the process itself is an improvement. 53 Figure 28. System blueprint. Discussion during workshops (co-creation sessions) often drifted to new ideas and possibilities, even if the topic of the discussion was in the present state of the process. Service blueprint provided itself as a valuable tool for discussing improvements with multiple stakeholders and over organizations. A number of key findings were made. First listed possible improvement was to source components earlier during the concept phase because that is the phase during which the system level decisions about technology are made. An interesting improvement opportunity was found the prototype manufacturing was discussed. It was revealed that the feedback loop from the prototype manufacturing could be improved by only sharing manufacturing documents that are already filled out to rate the manufacturability of any new product entering the manufacturing. These kind of improvements are of great interest because they do not require additional resources, only new feedback loops where data is used in a new context to create new value. It was discovered that there are pretty large batch sizes moving inside the product development process. Following the movement of these batches, co-creation sessions were able to discover possible improvements. Without even reducing the size of the batches that the literature proposed (Reinersten, 1997), improvement of the data inside these batches would reduce the time required for processing them. A concrete way to accomplish this was 54 discovered during the theme interviews with the CAD software vendor. A quick calculation estimated that the cost of this new software would be fully returned by using it to move just two large-sized batches in the process. This again reflected the findings from the literature when Reinertsen (1997) offered advice in favour of better tools because they should almost always be cheaper improvement options when compared to increased labour costs. Additional co-creation session results are listed in Table 10. Some of the proposed solutions are further discussed when case example project data are analysed and results between the analysis and the design thinking process discussed in more detail. Table 10. List of other co-creation results. User action: User pain points Ideas and possible solutions Ideate Early phase-gates are work intensive large batches, slowing the start of the “create” phase. Source component suppliers earlier in the concept phase. Create Workload is not distributed evenly. Smaller batch sizes inside the product development process for more concurrent engineering. More detailed design guidelines for manufacturing. Prototype Large batch size creates slow feedback loop. Project might have to go forward without receiving the feedback. Feedback loop back to the engineering in more detail. Challenging design choices (manufacturing as an outside expert). Test Changes between production batches indicate that more testing is needed (change requests created queues for engineering team). Last milestone before production approval could be split up. Refine Product data export batch size was large. Improved product data for production planning. Launch Rework occurred when quality criteria were not met in manufacturing. Change management benefits from improved product data (found in refine phase). 55 5.2 Frequency of work in progress arrivals As can be expected, the arrival of tasks into the product development process followed a closely normal distribution. Cumulation of work created the distinctive S-curve with characteristics like what literature proposed. This observation held when the process was examined as a whole and described the global shape of the resulting s-curve. Local changes in the s-curve revealed interesting remarks that reflected the user pain points. One reported user pain point was linked to the project milestones and how they were felt to prolong the product development process. This was an exciting finding because project milestones are usually described as crucial decision points that advance the project significantly. Nevertheless, by examining the WIP arrivals histogram, this prolongation was confirmed. When inspecting Figure 29, it was noted that the project's progress slowed down significantly during the significant milestones "Prototype A" and "Prototype B". The elongation of the project duration due to these large and mid-size milestones was noticed to extend to time covering eight histogram bins. Since one bin covered 15 days, the elongation was measured as four months. Another user pain point explained the feeling that the workload during the project is not evenly distributed. The literature covered this issue by explaining why the project follows the s-curve and not a straight line. The feeling was anyway correct assumption because when the s-curve was examined in more detail, it revealed that jump from 5 per cent of WIP arrivals (tasks started) to a state where 95 per cent of the tasks were already started happened only in duration of 16 15-day cycles. This meant that 90 per cent of the tasks were started during a time of eight months when the whole project lasted 24,5 months in this calculation. Again, the design thinking process results pointed to the correct issue that could be improved. 56 Figure 29. WIP arrivals. Going back to the investigation of the histogram and the S-curve itself, more observations were made about its shape. Rather than creating one sizeable S-shaped curve, the project resulted in multiple s-shaped curves that followed the significant project milestones. The project got to speed and achieved a peak in WIP arrivals, and then winded down when the project arrived at the milestone. A similar pattern was observed from the start of the project to the milestone “Prototype A”, between the “Prototype A” and “Prototype B”, and from “Prototype B” to the completion of the project. Literature supported this observation by explaining it to be a result of the large batch sizes that create queues in the system. In this case, it can be assumed that these large batch sizes delayed the arrival of feedback resulting in fewer created tasks (or WIP arrivals to the process). 5.3 Frequency of completed work WIP arrivals gave support for the user pain points found during the design thinking process. The user experience about the uneven workload during the product development process was also verified when another metric was used to inspect project data. A few essential improvement opportunities were revealed when a histogram of the frequency of completed work was plotted. If the purpose of the product development process were to take in a set of data (the idea of a product) and output a new set of data (product), this plot described that output frequency. WIP arrivals accumulation curve created an S-shaped curve, and the tasks were nearly normally distributed, if maybe leaning to the right by only a little. The same 57 observation was impossible to make when the completed work plot was investigated. The data (Figure 30) leans heavily to the right while creating a wave-like form in the frequency. Figure 30. Finished product documents. The plot confirmed that the workload was indeed not distributed evenly or even normally. Another user pain point was the uncertainty of why processing these product documents takes a long time, for example, when prototypes were ordered. The data revealed that the product documents were released as large-sized batches between the orders. Combined with the co-creation session information that a whole lot of product documents are processed as one batch, it was clear why this user pain point was existing. It was noticed that twelve 15-day cycles were passed before the first product documents were released. This translated to six months of time before factual product information was in a state that could have been shared with the manufacturer. This gave more meaning to the co- creation session, finding that discussions between manufacturer could be started earlier. By that measure, there was half a year available from which to begin to reduce that time. A combined histogram was last plotted (Figure 31) to find support to some additional user pain points. This histogram extended to a longer time, and in addition to the project duration, it covered the time to the current date. Since the product is currently in the production phase 58 of its lifecycle, more observations were possible to make related to changes in the product documentation. Figure 31. Combined long duration histogram. Product document releases appeared to continue regularly when the histogram plot was inspected. This reflected multiple user pain points but was also a signal of possible reuse of the product documents. The continuous release of product documents was equally linked to large number of changes between production batches – an issue that arose as a user pain point. But when those changes were linked to the reuse of the product documents in other projects the user pain point was solved by the understanding that this reduced demand for new product documents and allowed allocation of engineering efforts to entirely new endeavours. 5.4 Discussion The product development process as a value proposition to its users proved to offer unique views on how the process was inspected and how improvement opportunities were discovered. Organizations involved with product development processes are faced with complex challenges when simultaneously demanding a high return on investment from product development projects and trying to control the quality of that output by project management methods. This balance is delicate as it can create constraints to product development (Figure 32). Based on the theory of constraints (TOC), “any system must have a constraint that limits its output” (Leach, 2000). Leach (2000) explains that “if there were 59 no constraints, system output would either rise indefinitely or go to zero”. Because there is output data available as a result of the product development process, we must assume that there are also constraints that limit the output. During the research, user paint points found valuable insight about these constraints and the user experiences were further validated when the project data was examined, supported by the literature review. Figure 32. Constraints introduced into system. Based on the design thinking process, the defined users of the product development process identified the top-level project management model as the prevailing constraint limiting the output. Literature supported these findings by explaining these large batch sizes transferred in the top-level process as reasons why queues and delays occur in processes. Ellis (2016) offered an action plan to handle these constraints (Figure 33). He argued that the constraint is the critical chain of tasks that is mandatory for the completion of a project in a project. Since the case example company required all projects to meet specific gate criteria before the project can be finished, the project model itself could, in fact, be identified as the constraint. Figure 33. Dealing with constraints. (Ellis, 2016) 60 Because business environments are in the constant change, the findings made during the research are valid only for a certain amount of time. After the environment changes enough, a new constraint might arise that limits the output more than the now identified project management model. This emphasises the need for continuous improvement efforts also supported by the Lean principles. When design thinking tools are used for this continuous improvement of the product development process, the company enjoys better results due to the participatory and co-creation nature of the methodology. Research suggested for the company to investigate the product development project model based on the user experiences gathered during the design thinking process. The project model as the primary constraint was more evident when project phase gates were added to the graph. It was clear that the project model worked as an efficient model to control product development progress (Figure 34). The phase consisted of three batches of development work with variety in their sizes when compared to each other (Figure 34). Research suggested that if this project phase was still to be used as the development phase, it was possible to split it into smaller batches (Figure 35). Following the same cycle time with the project duration from gate 3 to prototype A (2 months of development time). Figure 34. Obtained process cycles data. 61 Figure 35. Proposed process cycles. This would enable the project and its client to get feedback faster back into the product development and alleviate the changes in the production batches since more feedback was used during the product development process. Another improvement would be the reduced level of errors, and the time it takes to discover them when the tested design solutions follow the principle of offering test specimens with a 50% chance of failure for the maximized new information generation. With these findings, this research concluded that the improvement of the product development process was indeed possible by using a design thinking approach. The user experiences on their own were enough to point out the pain points in the process. However, modern product development tools proved to provide valuable data sets for the research and further elaborated the state of the process in a way that was comparable to gathered user experiences. When the product development process was investigated with design thinking tools, three additional feedback loops were discovered to offer valuable information about the performance of the product development process. The improvement of the product development process is possible by monitoring feedback loops. For example, feedback loop A (Figure 36) could offer a faster way for the company to inspect the value-creation promise of the product than the traditional feedback loop (figure 34) of waiting how markets and customers react to the product. It was clear from the research that product development process users (engineering team) could be able to obtain data about the products value creation promise by examining feedback loop B coming from the 62 production to the manufacturing. The research concluded that data about the performance of the product was available in more quantities than was used at the time, suggesting that the improvement of the case example product development process could be achieved by utilizing these feedback loops more. Research proved that the feedback loop worked like intended when the design thinking approach was used further suggested that the continuous improvement of the system could also be achieved by implementing these design thinking tools into the product development process. Figure 36. Product development system feedback top-level Accessing feedback earlier in the product development process would enable a pull system promoted by the Lean principles. When the product development process produces prototypes earlier in the process, the process needs to get feedback earlier. This happens by pulling more information from the stakeholders to gather more information to enable the development of the next prototype. Using this kind of early prototype-pull system reduces the cost of change (Figure 37) and similarly the experienced risks when the client is offered more feedback loops. Concurrent engineering is very much at the centre of this solution since all product development areas of expertise are required to create prototypes: business case creation, industrial design, mechanical engineering, prototype manufacturing and sales. By utilizing all resources starting from the beginning of the process, the utilization of reserved resources increases optimally. The project should experience a more even flow of work of the product. Instead of transferring the business case to design, followed by transferring it to mechanical engineering and production, the project now moves the whole product as a whole. This way, the products' value will be more visible during the development process. 63 Combined with attention to feedback loops from the customer, production, and other business operations, the product development process dramatically increases its ability to deliver products with meaningful value for all those mentioned stakeholders itself included. Figure 37. Suggested prototype-pull system in effect. As a final discussion topic, the case study was examined as a whole, and a proposition for its improvement offered. The current relationship between the product development process and the project management model studied was disproportionate. While both had six identifiable phases, they did not align. Ratios between these phases can be seen in Figure 38. Figure 38. Currently used product development process versus project management model. 64 The product development process progresses only one phase while the project management model advances two phases. After this, the progress flips around when product development advances four steps (the main phases of the product development process) while the project management model advances only by one. After gate 3, the progress flips around again when the project management model starts to advance with three phases still ahead while there is only one left in the product development process. Literature best practices and design thinking approach results support a new model that is proposed. The proposed model removes the disproportional relationship between the two used models (or processes) (Figure 39). Figure 39. Proposed concurrent engineering product development project model. The product development process starts to advance in a concurrent manner, starting from the project model phase 1. After redefined progress has been made in all of the product development process tracks (Figure 39, six horizontal tracks, product development process), the project can move through the first project model gate (Figure 39, project management model gates). The proposed model follows Agile methods by starting all the development phases simultaneously and including all development phases in each project management model phases. The model is also in accordance with the design thinking methods by following the concurrent engineering method from the start of the product development process to the end of each development track. Not all tracks are meant to reach the end of 65 the project because this would mean that resources are wasted. It is not realistic that all of the product development tracks would take a similar amount of time to finish. Furthermore, as previously mentioned cost of changes in the product development process rises exponentially. To control the cost of change, the company using this model should introduce measures proposed in Figure 39 right side. In the proposed future state of the process, there are restrictions to complete the “Ideate” phase during the first three project management model phases (or before gate 3). Similarly, the “Launch” phase is done before gate six because it marks the end of the product development process and the project itself. 66 6 CONCLUSION The research was conducted to support the validity of the design thinking methodology to improve the product development process. Used triangulation method provided credibility for the method by providing a platform to discuss findings between the product development literature, process data and design thinking approach results. The design thinking approach was successful in its ability to find and develop possible improvements for the case product development process. The range of the possible improvements started from minor improvements to the current process that should prove easy to implement and offer immediate value for the users to the strategic level of thinking about the future of the process and the used project model. The variety of the results offers the case company the ability to plan short-term improvements and use them when discussing long-term plans for the product development process. The research focused on product development activities that follow the project management model. Hypothesis about the product development process as a value proposition for its users and stakeholders was put to the test. By viewing the process as a value proposition, the research was able to use design thinking methods for finding discussed process improvements. Different ways to improve this value proposition was found, but due to the research scope, further investigation is needed to establish connections between best performing product development processes, user experiences and in company’s ability to transform that value proposition to business growth. This research focused on identifying improvement opportunities from the current users of the process. Results obtained during this research can offer short-to mid-term planning, but early investments opportunities toward totally new technologies did not emerge. Advancements in virtual and augmented reality technologies could offer an alternative solution, such as previously time-consuming prototype manufacturing. In that case, the trade-off must be made between the value of involving manufacturing partners early in the product development process by testing the production flow and the product development projects ability to offer value for its other stakeholders by showing the prototype version of the product potentially much earlier during the product development project. 67 LIST OF REFERENCES Alves, A. C., Kahlen, F.-J., Flumerfelt, S. & Siriban-Manalang, A. B. eds., 2019. Lean Engineering for Global Development. Cham: Springer Nature. Beauregard, Y., Polotski, V., Bhuiyan, N. & Thomson, V., 2017. Optimal utilisation level for lean product development in a multitasking context. International Journal of Production Research, 55(3), pp. 795-818. Capasso, M., Treibich, T. & Verspagen, B., 2015. The medium-term effect of R&D on firm growth. Small business economics, 45(1), pp. 39-62. Childs, P. R., 2014. Mechanical design engineering handbook. Oxford: Butterworth- Heinemann. Cioffi, D. F., 2005. A tool for managing projects: an analytic parametrization of the S-curve. International Journal of Project Management, Volume 23, pp. 215-222. Clarke, R., 2020. Design Thinking. Chicago: ALA Neal-Schuman. Cooper, R. G., 2016. Agile-Stage-Gate Hybrids. Research-Technology Management, Issue January-February. Cooper, R. G. & Sommer, A. F., 2018. Agile-Stage-Gate for Manufacturers. Research- Technology management, Issue March-April, pp. 17-26. Costa, N. et al., 2018. Bringing service design to manufacturing companies: integrating pss and service design approaches. Design Studies, Volume 55, pp. 112-145. 68 Design Council, 2015. Design Council. [Online] Available at: https://www.designcouncil.org.uk/resources/guide/design-methods- developing-services [Accessed 06 04 2020]. Doorasamay, M., 2017. Product portfolio management best practices for new product development: a review of models. Foundations of Management, Volume 9, pp. 139-148. Ellis, G., 2016. Project Management in Product Development. Oxford: Butterworth- Heinemann. Folkestad, J. E. & Johnson, R. L., 2001. Resolving the Conflict between Design and Manufacturing: Integrated Rapid Prototyping and Rapid Tooling (IRPRT). Journal of Industrial technology, 17(4), pp. 2-7. Green Jr., K. W., Inman, R., Birou, L. M. & Whitten, D., 2014. Total JIT (T-JIT) and its impact on supply chain competency and organizational performance. International Journal of Production Economics, Volume 147, pp. 125-135. Grieves, J., 2000. Introduction: the origins of organizational development. Journal of Management Development, Volume 19, pp. 345-447. Kennedy, M. N., 2003. Product Development for the Lean Enterprise. First printing ed. Richmond: The Oaklea Press. Kraft, C., 2012. User Experience Innovation. New York: Springer. Ladyshewsky, R. K., 2010. The manager as coach as a driver of organizational development. Leadership & Organization Development Journal, 31(4), pp. 292-305. Lage Jr., M. & Filho, M. G., 2010. Variations of the kanban system: Literature review and classification. International Journal of Production Economics, Volume 125, pp. 13-21. 69 Leach, L. P., 2000. Critical Chain Project Management. Norwood: Artech House, Inc. Markovitch, D. G., Steckel, J. H., Michaut, A. & Philip, D. T. W. M., 2015. Behavioral Reasons for New Product Failure: Does Overconfidence Induce Overforecasts?. Journal of Product Innovation Management, 32(5), pp. 825-841. McCarthy, D. & Rich, D. N., 2004. Lean TPM: a blueprint for change. Oxford: Elsevier Butterworth-Heinemann. Mochida, S., 2013. A Study on Method of Measuring Performance for Project Management. s.l., 20th ISPE International Conference of Concurrent Engineering. Nielsen, K. & Randall, R., 2012. The importance of employee participation and perceptions of change procedures in a teamworking intervention. Work & Stress, 26(2), pp. 91-111. PMI, 2019. Practice Standard for Scheduling. 3rd Edition ed. s.l.:Project Management Institute, Inc (PMI). Polaine, A., Løvlie, L. & Reason, B., 2013. Servide design: from insight to implemention. New York: Rosenfield Media, LCC. Reinersten, D. G., 1997. Managing the design factory: a product developer's toolkit. New York: The Free Press, A division of Simon & Schuster Inc. Rittel, H. W. & Webber, M. M., 1973. Dilemmas in a General Theory of Planning. Policy Sciences, Volume 4, pp. 155-169. Salem, P., 2006. The seven communication reasons organizations do not change. Corporate Communications: An International Journal, 13(3), pp. 333-348. Sauser, B. J., Reilly, R. R. & Shenhar, A. J., 2007. Why projects fail? How contingecy theory can provide new insights - A comparative analysis of NASA's Mars Climate Orbiter loss. International Journal of Projects Management, Volume 27, pp. 665-679. 70 Sommer, A. F. H. C. D.-P. I. S.-J. K., 2015. Improved Product Development Performance through Agile/Stage-Gate Hybrids. Research-Technology Management, Issue January- February, pp. 34-44. Sommer, A. F. et al., 2013. Scrum Integration in Stage-gate Models for Collaborative Product Development - A Case Study of Three Industrial Manufacturers. s.l., IEEE IEEM. Stickdorn, M. & Schneider, J., 2011. This is service design thinking. New Jersey: John Wiley & Sons, Inc. Takeuchi, H. & Nonaka, I., 1986. The new new product development game. Harvard Business Review, Issue January-February, pp. 137-146. Urlich, K. T. & Eppinger, S. D., 2016. Product design and development. 6th Edition ed. New York: McGraw-Hill Education. Womack, J. P. & Jones, D. T., 1997. Lean thinking: banish waste and create wealth in your corporation. New York: Free Press.