Lean Six Sigma in New Product Development Lean Product Development combined with DfSS

(1)

Lean Six Sigma in New Product Development

Lean Product Development combined with DfSS

by

Rutger van Ruiten

Supervisor: Dr. J.W.J. Timans

Co-assessor: Prof. dr. ir. C.T.B. Ahaus 

University of Groningen

(2)

Preface

First of all, I would like to thank Dr. J.W.J. Timans for his tireless efforts reviewing and discussing the work throughout Master Thesis project and for providing the contact and support at company A, where the empirical research was performed. Second, I would like to thank Andreas Stoikos, with whom I have performed the empirical research. Third, I would like to thank company A and the interviewees for their time and for their clear answers in the interviews. Fourth, I would like to thank Prof. dr. ir. C.T.B. Ahaus, the co-assessor of this Master Thesis project. At last I would like to thank my family and friends who provided moral support and kept me motivated throughout the project.

Abstract

Purpose – Six Sigma and Lean production are well known concepts in academia and industry.

Both concepts have approaches associated with them that apply specifically to product development: Design for Six Sigma (DfSS) and Lean Product Development (LPD). Several attempts have been made to describe a possible merger between the two approaches but remain mainly theoretical. The aim of this study is to contribute to this discussion by collecting empirical data by means of a case study.

Methodology – First, a literature study was conducted in order to set up a theoretical

background for both DfSS and LPD. Second, an exploratory single case study of a new product development process was carried out. Data were gathered by means of 7 semi-structured interviews with engineers trained in the Design for Six Sigma method.

Findings – A possible merger between DfSS and LPD could prove to be beneficial, providing

guidance on both structure and content of the improvements efforts. The tools of DfSS may enhance and assure product quality, whereas LPD helps create flow and efficiency in the development process. By only implementing one of the two, the focus remains on either quality or efficiency and flow. A merger aims to balance these performance aspects.

Originality - This is one of the first explorative studies concerning the integration of DfSS and

LPD in industry. A standard way of working is being developed within company A, using the tools of DfSS while trying to increase the efficiency of the development process. The strengths of both approaches can be combined to improve quality and efficiency simultaneously.

Keywords – DfSS, LPD, Critical to Quality characteristics (CTQs), workload levelling, cross

(3)

1. Introduction

In the field of industry there is a constant search for new ways to optimize production processes. This is done mainly by minimizing variation while still meeting the requirements of the customer (e.g. product quality). Six Sigma is an approach that has been adopted by leading companies throughout the world to help solve such problems (Hahn et. al 1999). The Six Sigma approach has gained widespread acceptance as an improvement methodology to enhance an organization’s competitiveness (Lee & Choi, 2006). Six Sigma proves to be effective in improving production processes and meeting customer requirements. But what about the quality being delivered in the earlier phase of product development? According to Koch, Yang, & Gu (2004) it has long been recognized that the quality or performance of a product is dependent on earlier design decisions. Design for Six Sigma (DfSS) is an approach that has evolved within Six Sigma to help guide the designing process of a product. The major objective of DfSS is to “design things right the first time” (Sokovic, Pavletic, & Pipan, 2010 P.184). According to He, Tang, & Chang (2010) around 75% of the product cost is determined when a design is released. Moreover, the performance of a product is also determined by early design choices (Koch et al., 2004), which again emphasizes the role of DfSS.

(5)

efficiency in the product development process and only have value added activities (Liker & Morgan, 2006; Ward 2007). LPD practices focus on deploying cross-functional teams and making use of concurrent engineering (CE) (Karlsson & Ahlstrom, 1996). CE holds that activities are performed in parallel and not in sequence. For example, the production engineers can start preparing the production line when a product is still being designed (Gremyr & Fouquet, 2012). These practices ensure a better integration of functional aspects and a faster market launch.

Both DfSS, focusing on the CTQs, and LPD focusing on efficiency and value stream, appear to have positive outcomes on performance. In the light of LSS it might be worthwhile to investigate a possible merger of these two approaches. Since both approaches have similar interests, like increasing quality, faster innovation and creating customer value, it is thought that the strong points from both approaches can be merged. DfSS uses effective tools to strengthen quality in every stage of the product development process. A weakness of DfSS is having less focus on improving the development process itself, which is one of the focus points of LPD. On the other hand, LPD is not focused on the robustness or reliability of a product, this is where DfSS has its strong points in improving these aspects. LPD and DfSS are not interfering with each other, rather the approaches are mutually complementary (Yang & Cai, 2009). Some attempts have been made by authors trying to combine the DfSS approach and LPD with the aim of increasing quality and adding value to the customer in the early product development phase (Yang & Cai, 2009).

(6)

The aim of this study is to increase our knowledge on the integration of LPD and DfSS and the question whether this can be applied to the development process of a product in industry. The following research question has been formulated to explore this topic:

How can LPD be combined with DfSS in a development department of a product in industry?

This study aims to contribute to the field of literature on LSS in industry by exploring how the development process can become more efficient with shorter development times and simultaneously take quality into account. Case research will be used to explore and build knowledge on the integration of LPD and DfSS. A company in which DfSS is applied in the product development process will be part of the case study, this company will be referred to as ‘company A’. Semi-structured interviews were conducted at company A to collect data regarding their product development process. The interviews were held with employees in several departments relating to the new product development. The findings from the empirical research will be discussed in combination with relevant literature. From a theoretical point of view, the aim is to explore the combination of DfSS and LPD in the development phase. For instance, are there strong points of both approaches that could lead to a successful merger? From a practical point of view, the aim is to gain insight into how the two different approaches are used and how possible benefits can be reached by integrating these approaches. Benefits, for instance, can be a decrease in time to market with increased quality of a product, hopefully exceeding customer demands, at lower cost.

(7)

2. Theoretical background

The following chapter will present a discussion of literature on DfSS and LPD. The relevance of both approaches will be discussed, followed by the evaluation of a possible integration of both approaches.

First and foremost, it should be noted that, in the early stages of a product life cycle, a large part of the costs is determined in the development phase. Therefore, it is important to determine which performance measures may be used when improving the development phase of a product. Performing an in-depth analysis on performance in product development, Driva, Pawar, & Menon (2001) found that costs, quality and time to market are most frequently used as performance metrics. It would be worthwhile to discuss how both DfSS and LPD can be used to reach a satisfactory performance.

As discussed earlier, 75% of a product’s costs are determined by the time a product design is released (He et al., 2010). It should be noted that it is hard to identify possible mistakes already in the design phase. In the stage of manufacturing a defect might be easier to identify, but the cost of solving the problem will have increased significantly by then (Berryman, 2002). Hence, design choices affect the costs in the later stages of production as well as the product’s performance (Koch et al., 2004). By defining Critical To Quality requirements (CTQs), a company knows what characteristics a product should have in order to answer to customer demands.

DfSS has evolved within Six Sigma as an approach to guarantee these CTQ requirements into the product already in the development phase (He et al., 2010). LPD is an approach that focuses on improving efficiency and creating flow in the development phase of a product or process. Balancing the focus between quality and efficiency remains a challenge. Both should be accounted for and should not be improved at the expense of the other (Gremyr & Fouquet, 2012). Both DfSS and LPD will be elaborated on further to provide a theoretical background of both approaches.

(8)

(Gremyr & Fouquet, 2012). As stated by Smith (2001), whereas Six Sigma is used mainly to solve problems in the production process, DfSS is focused on preventing such problems from occurring. DfSS can be applied in the development phase of the product. The development phase is the best phase to prevent problems and built-in quality right from the start. Two different aspects of DfSS may be discerned: on the one hand there is the cycle a DfSS project follows, on the other hand there are the tools that may be deployed to improve quality. First the different cycles will be explained, followed by an explanation of the different tools.

One of the goals of DfSS is to help design products that may be produced at a high-quality level. This starts with understanding the customer’s needs. The so-called Voice of the Customer (VOC) is important to take into account while developing a product. The needs of the customer may be translated into CTQs, so that these CTQs may be built into the design. (Yang & Cai, 2009). Through the implementation of preventive thinking and the use of tools, the CTQs may already be built into the product in the product development phase (Berryman, 2002).

When applying Six Sigma to improve production processes, the DMAIC-cycle is used. Sokovic et al. (2010) describe the DMAIC-cycle as a data-driven life-cycle approach to improve processes in Six Sigma projects. The authors (p. 480) specify the DMAIC-cycle as follows “(the DMAIC-cycle) is systematic and fact based and provides a rigorous framework of results-oriented project management.” The five consecutive phases of DMAIC are the following (Koning & Mast, 2006, p.773):

- Define: Define the problem that needs to be solved, incorporating customer impact and potential benefits.

- Measure: Determine the critical-to-quality characteristics (CTQs) of the product or service. Measure the unsatisfactory performance and establish improvement goals. - Analyze: Recognize the root causes of where performance can be improved: diagnose

key process variables which cause bad performance.

- Improve: Define the way to intervene in the process in order to greatly improve the performance and tests interventions of effects on CTQs

(9)

an existing situation. In the development phase, there is no existing product yet with features that need to be improved. Therefore, two main approaches are used in DfSS projects. IDOV is used when designing new products or services and DMADV is used when designing new production processes to meet Six Sigma quality (Sokovic et al., 2010). The steps of IDOV are the following:

- Identify: identification of customer critical-to-quality characteristics (CTQs); determination of the relationship between customer requirements and technical requirements.

- Design: analysis of the design requirements and key design parameters and their relationship with CTQs; utilization of concurrent engineering practice.

- Optimize: optimizing the design to ensure CTQs are met. Determination of design capability and comparison with design specifications

- Validate: verification of the design to ensure that it meets the set requirements; assessment of performance, reliability, capability

(Antony, 2002 P.8)

In most literature, the last step is depicted as Verify, but Antony (2002) used Validate. The DMADV-approach is considered when designing a new process. It is more connected to the DMAIC-cycle, but it is applied to designing new processes rather than improving existing ones (Sokovic et al., 2010). There are some differences between the cycles, however. The Design phase is more suitable in DMADV. A process can be designed from scratch, instead of improving an existing process. Besides, the design of the process is verified if it meets all the specifications. The steps of DMADV are Define, Measure, Analyze, Design and Verify. Since the focus of this research is to look at the design of new products or redesign of existing products, the IDOV-cycle is later discussed in combination with the empirical findings. The DMADV-approach is discussed to create the right theoretical background, but will be left out of the empirical research.

(10)

fostering communication in cross-functional teams (Haque & James-moore, 2004). The use of QFD may be linked to the practice of Concurrent Engineering, which is one of the practices used in LPD. This will be elaborated on in the following chapter.

To test the performance of a product, a Failure Mode and Effect Analysis (FMEA) can be deployed as an advanced type of risk analysis. It is used to evaluate and improve a product, process or design by assessing potential risks and failures and their effects. The purpose is to identify risks in advance and take actions to reduce or eliminate failures in the early phases of development (Ericsson et al., 2010). This could be linked to the LPD approach, that aims to create flow and eliminate waste in the product development process.

LPD

Several authors have recognized that Lean plays a role in the development process of a product. The competitiveness of successful firms is based on their ability to balance innovation and product quality with cost-effective product development. Costs may be interpreted in many ways, such as rework, wasteful activities or unnecessary long development times. The aim of LPD is to improve efficiency, to maximize customer value and to do so with minimum waste of resources. The question how to create a more efficient development process has been discussed in the work of Hoppmann, Rebentisch, Dombrowski, & Zahn (2011). These authors conducted a literature study identifying the practices of LPD. It was found that working in cross-functional teams integrates different functional aspects, increasing the efficiency and creating more alignment between departments. Knowledge may be shared by different experts, bringing together experiences of the whole process from designing a product up to sales (Karlsson & Ahlstrom, 1996; Liker & Morgan, 2006; Womack, Jones, & Roos, 1990). For instance, information and knowledge may be shared between functions like marketing, engineers and manufacturing. Retaining knowledge from earlier projects and sharing information at the right time can help reduce the development time of a product (Yang & Cai, 2009). These thoughts are also shared by Mourtzis, Papathanasiou, & Fotia (2016). The sharing of information and knowledge is elaborated upon in their proposed lean design rules. The following rules with regard to information and knowledge are proposed:

- Designers should always try to exploit past knowledge from similar cases. The drawings of those cases should be used as a basis for the new design.

- Information/Data gained through a design process should always be stored and be available anytime, for similar work /remanufacturing.

(11)

those components require modifications. (Mourtzis et al., 2016, p. 201)

Concurrent engineering

Concurrent engineering (CE) is a practice that might be interesting to use in the development process as a means of increasing efficiency. Firms using CE have reorganized the product development process from a sequential process to a concurrent process, where activities from product/process engineering, manufacturing planning, marketing and sourcing activities overlap (Koufteros, Vonderembse, & Doll, 2001). The CE practice could be linked to the IDOV cycle. The test engineer, for instance, can already start preparing a test being performed in the Verify phase when the product specifications are improved upon in the Optimize phase. CE is having concurrent work-flows, product development teams and early involvement of constituents, for example, including the marketing department when developing a product (Koufteros et al., 2001). The QFD tool used in DfSS may be linked to the CE practice. Cross-functional teams are needed to develop the QFD, making sure each design specification meets the customer needs. Different functions are involved while subdividing the design quality into subsystems and component parts, ultimately to specific elements of the manufacturing process (Haque & James-moore, 2004). The different layers from design quality all the way down to the processes require different functions to be involved.

(12)

Integrating DfSS and LPD

(13)

3. Methodology

Defining the method

Since little research is available concerning the integration of LPD and DfSS a case study has been conducted. Both the approaches of DfSS and LPD were studied in a natural setting where these are applied. The case study consists of interviews, which allows for the collection of large amounts of qualitative data through observations of the phenomenon. By observing actual practice, relevant theoretical insights may be gained (Meredith, 1998, p. 444). The unit of analysis is the development department of a new product. By conducting interviews, probing questions may be asked during interviews if answers remained unclear. When using surveys this contextual richness cannot be gained (Sousa & Voss, 2008 P. 697). The aim is to develop a theoretical base on the unexplored area of Lean in DfSS projects. For this reason, case study methodology is chosen as the most appropriate option.

Research setting

(14)

Case selection

The choice has been made to look into the design department of a single company applying DfSS. The interviews were held with 4 Black Belts and 3 Green Belts (BBs and GBs) of three different departments responsible for the design of new products or the redesign of existing products. The original number would be 4 BBs and 4 GBs, but due to circumstances one of the interviewees had to cancel the interview. No other departments than the ones directly involved in developing the products were included in this study. In Figure 3.1 the properties of the interviewees can be found.

Interviewee Education Level Years at the

company Years current position GB / BB Department A Master in Mechanical

Engineering 8 months 8 months GB I

B Master in Mechanical Engineering

and Industrial Design

3.5 years 2.5 years GB NPI

C Master in Mechanical

Engineering 18 years 6-7 years BB NPI

D Bachelor in Mechanical Engineering

(University of applied sciences)

27 years 7 years BB AD

E Master in Mechanical Engineering

12 years 5-6 years BB I

F Bachelor in Communications

(University of applied sciences) 4 years 4 years GB I

G Bachelor in Process and production control

(University of applied sciences)

15 years 1 year BB AD/NPI Figure 3.1

This single case study has led to great depth looking into the different approaches. However, because it is a single case study, it might be hard to generalize the conclusions. Only very few companies in the Netherlands apply the DfSS method on similar scale. Especially having trained numerous BBs and training so much GBs. This made it hard to find similar cases.

Data collection

(15)

be discussed in the findings and discussion. Reliability is important to safeguard the quality of the research (Karlsson, 2009, p. 182). A case study protocol is used to increase reliability and to help keep the interviews standardized. The protocol (interview guide) can be found in the appendix. Part A and part C are relevant to this research. Before the interviews were conducted, the interviewee was sent a general outline of the research, along with information on the interview and some sample interview questions. Each interview was recorded in order to guarantee smooth interviews. The aim of the interviews was to explore the integration of LPD and DfSS. The interviews were held at the location of the facility the interviewee is working at. The interviews took between 60-90 mins. Part A took up to 10 mins, part B 40 mins and part C 40 mins. The interview was conducted along with a fellow student, who performed a different research in relation to DfSS. The general questions in part A of the interview are used in both studies, part B of the interview is related to the study of the fellow student and part C is used for this study. Some probing questions have been used in the interview when answers were not clear or required further explanation. To give an overview, three example interview questions are provided:

- How does company A define its time planning?

- How are different departments integrated in the different phases?

- How does company A retain/share knowledge from earlier and current projects?

The interviews were transcribed shortly after the interview took place, in order to avoid misconceptions of data or a change on behalf of perceptions of the interviewer. Each interviewee received a follow-up email with the transcripts of the interview and each interviewee verified the transcripts.

Analysis

(16)

already known that the company applied the DfSS method. Hence, the aim of interviews was to see if LPD practices where used as well and whether or not an integration of LPD and DfSS is possible. An example of the coding tree can be seen in figure 3.1. The whole coding tree is displayed in the appendix.

Cross functional teams

Alignment “Sometimes it is hard to align the work, because engineers want to be free in the beginning of the project.”

“Yes, it is fine to take over work of other departments, as long as decisions are aligned”

“Regular meetings with the team help us to stay aligned.”

Departments “The people working at other departments are needed to consult solving those problems.”

“It is the most efficient way to develop a product. If you see our projects you see there is always one person of the industrialization department and one from NPI, and you have the production.

“You need the representatives from each department to check if you did everything right.”

Meetings “We have a meeting room where we have all the team meetings at that place.”

“When you are in the project you have team meetings. Once or twice a week. Where you discuss what needs to be done and how far the current work is.”

Concurrent engineering

“We are using the experts from AD when we have to challenge something when a process proves to be not capable for us.”

“It makes it possible to develop faster, but it also gives a lot of friction. Because as a function developer you might want to change a part, but then at the production department the producers already have the molds in place. It is sometimes hard to meet these new requirements.

“Because the idea within Company A is that you investigate in advance if a function is feasible.”

Figure 3.1

(17)

4. Results

The results will follow the structure of part C in the interview protocol, which is subdivided into four different topics. These topics are 1) the general knowledge of each interviewee on DfSS and LPD, 2) work load leveling and performance, 3) working in cross-functional teams, and 4) the sharing and retaining of information and knowledge. The codes introduced earlier will make up the headings of the results section.

DfSS and LPD

All of the interviewees where familiar with DfSS and are certified either at the Green belt level or the Black belt level. The DfSS cycle used at company A is a bit different to the IDOV-cycle described earlier. Within the company two additional phases are used before and after IDOV, creating a DIDOVM-cycle. In the Define phase the business metrics, such as the budget for the project, the expected performance and planning, are set. At this stage the team is constituted, involving the different departments in a cross-functional team. After the business metrics are agreed upon, the project sign off takes place and the project can enter the Identify phase. The Monitor phase starts when the product is verified and taken into mass production. In this phase data are gathered over a long term in order to measure the performance of the product when launched. The interviewees are trained in using the whole cycle, but are not involved in each step of the cycle. Most of the follow only one or two steps. For instance, the Industrialization department is involved in the Verify and Monitor phase. The departments are Advanced product development, New product innovation and Industrialization

(18)

DfSS tools

A common tool used in DfSS called QFD is used in company A to determine the different CTQs of a product. The QFD tool helps to translate customer demands into technical and design specifications. Knowing the different CTQs it is important to know their relation to each other. All CTQs can be placed on different levels and have their effect on overall performance in the end. A useful model used in company A is the CTQ flowdown, this shows the relation of CTQs group in different levels. The CTQ flow down is presented as a V-model, following a flow down starting with the higher level CTQs describing the customer demands and or business requirements, all the way down to the lowest level CTQs describing the process requirements. Figure 4.1 provides the V-model as used in company A.

Figure 4.1

(19)

influence the higher-level design requirements, eventually influencing the whole product design. Within company A different departments are involved in determining and testing the different CTQs, making it critical to be aligned and making sure information regarding the design is easily accessible.

Another tool that helps give an overview of all CTQs is the Design Dashboard. This is usually a display or interface that can be accessed via a computer. The dashboard helps company A visualize the business and production goals and collects real-time data. The dashboard helps monitor processes and shows parameters of the different CTQs. The dashboard is extremely useful, as the capability of the design can be shown before the actual product is created. The following example of interviewee A illustrates the relevance of the design dashboard: “If you have a CTQ that is just out of limit, not meeting specifications, the effect of the CTQ can be checked on the design dashboard and whether the performance will be enough with wider specification limits.” The effect of a CTQ can be checked either in an early stage or later, when the CTQ is already built into the product, causing an efficient development process. The design dashboard is an effective tool in sharing and quickly accessing information regarding the product design built up from the different CTQs. Each department can access and verify the capability of the design, which the engineers influence all together trying to meet the set specifications.

(20)

Cross-functional teams

Within company A working in cross-functional teams while designing a product is highly valued. According to the interviewees, the way of working is the most efficient. This way it is easier to share information between functions and make sure that the decisions of the employees are aligned. A unique aspect of working at company A, according to the interviewees themselves, is that the innovation department, the engineering department and the production department are all located at the same facility. This guarantees close proximity between the departments and makes it easy to discuss issues in cross-functional teams. The following quote is from interviewee D “I think it is the most efficient way. You don’t see it anywhere else that you have the innovation department and the engineering department and the production department in one location.” Marketing and sales are located in a different office, but the departments are closely involved and participate in regular meetings discussing the design of a product. When conducting a team, it was emphasized that from each department 1 or 2 representatives should be involved, depending on the importance of certain aspects. Depending on the stage a project is at, the input of each member differs.

(21)

Knowledge Management

Within company A the interviewees value the fact that every employee of each department involved in the development is trained in DfSS. The interviewees value that the same language is spoken and knowledge is dispersed throughout the whole design process. When an employee enters the company without any certification, the engineer is first educated and trained up to GB level. From advanced development department, up to the industrialization department, most of the engineers are trained. This not only helps the employee understand the tools they work with, but also ensures that everyone understands the steps of the project. The interviewees stated that by training the employees in the DfSS approach, a common language is created that is used and understood by everyone. To become a GB, the theoretical DfSS training that is required takes around 6 days of education, followed by a written exam to test the knowledge. After passing the exam, the employee is ready to lead a DfSS project and use the DfSS techniques. The aim is to be fully GB certified within 1 year after starting the project. During this process, a BB will supervise and guide the trainee into becoming a GB. The different black belts guiding the training meet every 4 weeks to discuss the progress and how to continue the projects. At the end of a project the trainee discusses the work with a BB, which is later presented on a A0 poster. An assessment committee will discuss whether or not the delivered work is sufficient. If sufficient, the poster can be presented at a certification event and the trainee can be GB-certified. At this event, the green belts have to present their projects and knowledge on a A0 poster. After certification, no further training is given. The use of DfSS tools is incorporated into the way of working at company A, just like the IDOV-cycle with two additional phases. No evidence has been gathered on the reasons for not having complete DfSS projects after certification. No specific LPD training is given in the development departments.

(22)

Information regarding the design of the product is stored in a product life-cycle management system. Each employee at every stage can search for information on the whole product.

Best practices are logged of important lessons learned, that can be valuable for future projects. The learning experiences are either written down in a research document or presented in a PowerPoint and then stored in a database. Creating learning experiences is part of the deliverables of a project. At the end of a project is determined what should be documented. The database can be accessed with the help of a search engine. In the database, you can find all kinds of information stored from earlier projects. At the start of a new project it is compulsory to check the learning experiences from previous projects, which makes the development process more efficient. Moreover, the past experience of projects helps determine the planning of a new project. Nevertheless, although a lot of information is stored, it is recognized that the accessibility of the data can be improved upon. There is a lot to be found, but there is not always a clear overview of the useful data. At the moment company A is developing a standard way of working method (SWI) in which the learning experiences of former projects are linked to the road map of a project. For each step taken in the project the employee is informed which learning experiences might be useful, increasing the efficiency in the end. The SWI will be discussed in the following chapter.

Workload leveling and performance

Good planning helps ensure the progress and clarity of a project. Company A applies Lean planning, which is a helpful tool to link the execution of the work to the overall planning of the project. This approach differs from a traditional approach, where the planning and the execution of a project are separated. Lean planning combines planning and execution into one schedule. It shows the planning in terms of time, but also the progress of the work at a certain point. Lean planning is useful in projects with a wide range of activities in which different departments are involved. An activity is performed only when needed and at the right time, preventing waiting times or wastes of resources. The planning is reviewed regularly by the cross-functional teams and the team acts accordingly.

(23)

and deadlines are discussed for the project planning. Level 2 planning determines what work has to be done to reach a certain milestone. So-called work packages are assigned to a milestone. These work packages describe the work that has to be delivered in a certain number of weeks. It visualizes the decisions that have to be made and the steps have to be taken before proceeding to the next phase of the project. Level 3 planning provides the most detailed planning on a weekly basis, made on a more personal level. The whole planning is visualized and frequently discussed in meetings. Figure 4.1 shows a visual representation of the levels of planning.

Figure 4.1

To make sure each employee is able to adhere to the planning, the workload of each employee is made visual next to the planning. The employees can assign colors to their workload: with green meaning more work can be assigned, yellow meaning the employee has a sufficient amount of work and red meaning the employee has a work overload. When this becomes a problem, it is given priority in the team meeting and the priority of the problem is set. The work is subsequently reassigned either within the department of the employee itself or to other departments. This not only helps ensure that the time of every employee is planned in the most efficient way, it also makes sure that every piece of work is completed on time. Key is that these team meetings takes place on a regular basis, this which guarantees the most efficient way of working.

Beside using the Lean planning, company A is developing a standard way of working called the Standard Work Industrialization (SWI). The SWI is being developed in the Industrialization department. This SWI is still in the early phase of development. At the moment one department is testing the usefulness of using the SWI. So far, the experiences have been good. Former projects are analyzed and standards are developed based on the questions what work has to be

(24)

steps, using prior knowledge and information. It is recognized that certain steps are almost always needed and other less frequently. Within company A the aim is to develop a road map of a project, integrating the tools of DfSS with the Lean planning. According to interviewee C company A would like to link the tools of DfSS to this SWI to know what has to be done and when. To provide an example, a simplified version of the SWI is shown in figure 4.2

Figure 4.2

As can be seen, the tools of DfSS can be linked to the project planning. For instance, when a certain test is scheduled in a work package (Lean planning), a DfSS tool is linked to this work package. This SWI creates an overview of the project from start to end, telling the engineers what to do at each step. A lot of tools can be deployed, but not all tools have to be used in each project. The SWI helps Company A develop a standard on how to deploy projects and ensures an efficient planning on what needs to be done and how it should be done. It is recognized within company A that a lot of steps are taken that the customer might not see directly as valuable. The focus for company A is delivering quality and maintaining its name as a high-quality brand. The priority is to deliver the right high-quality within the current development process. The SWI can help to increase the efficiency of this process.

(25)

5. Discussion

Integration of DfSS and LPD

Taking a quick look at the theoretical background, it could be argued that DfSS and LPD have a different focus. However, both approaches are not mutually exclusive, but rather mutually complementary. The aim of this discussion is to give insights for the integration of DfSS and LPD. Since DfSS is known to focus more on quality, whereas LPD focuses more on efficiency, the following questions will be discussed: How does DfSS contribute to LPD in terms of efficiency? And how does LPD contribute to DfSS in terms of quality?

How does DfSS contribute to LPD in terms of efficiency?

In the work of Ericsson et al. (2010) the possibility of linking certain DfSS tools to LPD in terms of efficiency was raised. In this work, the use of QFD and FMEA is discussed as a means of increasing the efficiency of the development process.

Reporting the results of the interviews, these tools were found to be applied in the way of working at company A. The interviewees recognized that these tools help create an efficient process. The QFD is used to first identify each CTQ and to subsequently link the CTQs to each other, creating a CTQ flow down. Following the flow down is the capability to flow up, testing whether all specifications of the different CTQs are met. This tool helps map out all the links between the CTQs and tell how performance will be influenced if one of these CTQs does not meet specifications. Within company A different departments are responsible for developing and meeting the separate CTQs, which makes the flow down a useful tool to link to the concurrent engineering practice. The use of the QFD tool was already linked by Haque & James-moore (2004) to concurrent engineering, who argue that the use of QFD fosters cross-functional working. Using the CTQ flow down increases the efficiency by aligning the different departments and testing whether or not each specification is met. A slightly similar tool was found in company A, which the engineers use to make information of the product available in each step of the process.

(26)

limits can be adjusted without affecting the overall performance of a product. The use this tool has not been linked directly to either DfSS or LPD. However, seeing the usefulness, it could definitely add something. Analyzing and mitigating risks is of vital importance to the performance and success of a product. It would be most efficient to identify risks beforehand and try to mitigate these risks early in the development process. Ericsson et al. (2010) linked the use of FMEA to the LPD practice in terms of efficiency. It is a useful tool to recognize risks early on and act accordingly. This was found in company A, where lots of FMEA’s are performed on the level of the customer (end-user), on process level and on design level. The tools mentioned not only help the process become more efficient, but also help to share information and make this available during the whole development cycle.

Each tool has proven its usefulness and could be deployed in every development project. However, at company A the engineers want to take the planning of a project to a whole new level. At the moment, a Standard Work Industrialization (SWI) is being developed. This new method may turn out to be a combination of LPD and DfSS. This may be done by creating a standard for the deployment of a project by knowing what DfSS tools could be deployed and when, as well as integrating a Lean planning, with the SWI guaranteeing that each step is taken on time. The SWI is adjusted each time based on experience from former projects, in an attempt to standardize the steps taken for a certain project. It ensures that every step taken is of value to the project. The SWI shows what DfSS tools should be used at each step and the Lean planning helps divide the work load per employee. This combination makes sure the right quality is delivered through an efficient planning of the work load. This SWI is found within company A, but has not been described in literature yet. However, some components may be linked to the literature, looking at the Lean design rules made by (Mourtzis et al., 2016):

- The designer should always try to exploit past knowledge from similar cases. The drawings of those cases should be used as a basis for the new design.

- Information/Data gained throughout the design process should always be stored and be available anytime for similar work/remanufacturing.

- The designer could use/exploit standardized components as much as possible, even if those components require modifications.

(27)

need to be assessed and are linked to the different steps in a project. Information and knowledge of projects is stored and made accessible through databases and shared in frequent meetings. The third design rule is also followed when an existing function of a product needs to be adjusted to a new design. However, this is not directly linked to the SWI. The SWI more or less creates a road map for an integrated planning.

How does LPD contribute to DfSS in terms of quality?

The different LPD practices are mostly described as enhancers for efficiency and for creating flow in the development process. However, the different practices can also be linked to improve quality. For instance, Shah & Ward (2007) state that an unleveled workflow overburdens employees and thereby decreases the quality of their work. Using a Lean planning balances the workload for each employee on a daily basis and creates flow in the development process. Within company A it was found that a Lean planning was used to plan the development projects. The Lean planning helps combine the project planning with the work that needed to be done. The Lean planning aids in visualizing the work load of each employee on weekly basis. The work load can be leveled accordingly, creating flow in the end. Next to having the work load leveled, it is important that each department is aligned. When deploying CE working in parallel with the different CTQs of the CTQ flow down, a cross-functional team may prove to be highly useful.

(28)

quality in the end. If information is shared properly and readily accessible, this not only increases efficiency but in the end, helps align each department in their decisions. At the start of a project, employees are encouraged to take a look at former projects and the learning experiences gained from them. This could already increase the quality by implementing knowledge of former projects. The employees recognized that the recording and use of these learning experiences can be improved within company A. According to Yang & Cai (2009) delivering learning experiences should be a compulsory task to retain information. However, it could prove even more beneficial to show the employees the usefulness of the learning experiences, possibly making the employees more intrinsically motivated to create and use these learning experiences. These learning experiences may for instance be linked to the SWI, increasing quality and efficiency at the same time.

Theoretical contribution

The most novel aspect of this research, and what can contribute to literature on this subject is the SWI being developed and used within company A. The integration of DfSS and LPD has not yet been studied in a real-life case. By developing an SWI the development process will become more efficient, taking quality and flow into account at the same time. DfSS and a Lean planning can be integrated into this SWI, creating continuous learning and optimizing the development process. Linking a Lean planning to the SWI helps give an overview of the whole project planning and linked to the roadmap of a project. The SWI is more than only a Lean planning, it tries to standardize the development process, decreasing the lead-time and improving the quality of products in a development project.

Practical contribution

(29)

6. Conclusion

The aim of this study was to contribute to a possible merger between DfSS and LPD. Both approaches use different tools and techniques that can be mutually beneficial rather than mutually exclusive. The tools of DfSS build quality into a product and make sure the different CTQs are built in right from the start. The practices of LPD can help organize the development process itself and guarantee an efficient planning. Key is the alignment of each department involved in the development of a product. The cross-functional teams help to align all members. The Lean planning helps break down the overall planning to small personal workloads per employee, creating flow between the successive steps. The SWI standardizes the projects up to a certain level, decreasing the lead-time of a project. Moreover, the waste of knowledge is brought to a minimum, on the one hand by having learning experiences as a deliverable. Improving the SWI and learning experiences each time will help future development projects become more efficient, so that higher quality can be delivered. Using both DfSS and LPD can enhance efficiency and quality, whereas using one of the two approaches might lead to lower results.

Limitations and Future research

The first limitation of this research is that the interviewees where only educated in the DfSS methodology and not in using LPD. Only a few companies deploy the DfSS method, which made this study a rather unique chance to study DfSS in a natural setting. The conclusions from the chosen context, a single in-depth case study of projects in an LSS industry might not be completely generalizable to the rest of the industry. It is therefore suggested that other industries are explored as well, using qualitative research to make a comparison between the results. A third limitation could be that the researcher was not fully educated in the use of DfSS and LPD. The researcher had to invest a lot of time in gaining an understanding of the different concepts and might be biased based on the literature he read.

(30)

7. References

Alvarez, J. C. (2015). Article information : International Journal of Quality & Reliability Management, 32(8), 895–905.

Antony, J. (2002). Design for six sigma : a breakthrough business improvement strategy for achieving competitive advantage. Work Study, 51(1), 6–8.

Berryman, B. M. L. (2002). DFSS and Big Payoffs. Six Sigma Forum Magazine, 2(1), 25–28. Clark, K. B., Chew, W. B., Fujimoto, T., Meyer, J., & Scherer, F. M. (1987). Product

Development in the World Auto Industry Linked references are available on JSTOR for this article : Product Development in the World Auto Industry. Brookings Papers on Economic Activity, 3, 729–781.

Driva, H., Pawar, K., & Menon, U. (2001). Performance Evaluation of New Product

Development from a Company Perspective. Integrated Manufacturing Systems, 12(5), 368–378.

Ericsson, E., von Würtemberg, L. M., & Lilliesköld, J. (2010). Integrating DFSS and Lean product development: Using Project Management Success Factors to Evaluate Product Development Concepts. ASQ world conference on quality and improvement, 64, 1–14. Gremyr, I., & Fouquet, J.-B. (2012). Design for Six Sigma and lean product development.

International Journal of Lean Six Sigma, 3(1), 45–58.

Hahn, G. J., Hill, W. J., Hoerl, R. W., & Zinkgraf, S. A. (1999). The Impact of Six Sigma Improvement—A Glimpse into the Future of Statistics Gerald. The American

Statistician, 53(3), 208–215.

Haque, B., & James-moore, M. (2004). Applying lean thinking to new product introduction (Vol. 15).

He, Y., Tang, X., & Chang, W. (2010). Technical Decomposition Approach of Critical to Quality Characteristics for Product Design for Six Sigma. Quality and Reliability Engineering International, 26, 325–339.

Hoppmann, J., Rebentisch, E., Dombrowski, U., & Zahn, T. (2011). A Framework for

Organizing Lean Product Development. Engineering Management Journal, 23(1), 3–15. Karlsson, C., & Ahlstrom, P. (1996). The Difficult Path to Lean Product Development.

Journal of Product Innovation Management, 13, 283–295.

Koch, P. N., Yang, R., & Gu, L. (2004). Design for six sigma through robust optimization. Structural and Multidisciplinary Optimization, 26, 235–248.

Koning, H. De, & Mast, J. De. (2006). A rational reconstruction of Six-Sigma ’ s

breakthrough cookbook. International Journal of Quality & Reliability Management, 23(7), 766–787.

Koufteros, X., Vonderembse, M., & Doll, W. (2001). Concurrent engineering and its consequences. Journal of Operations Management, 19, 97–115.

Lee, K., & Choi, B. (2006). Six sigma management activities and their influence on corporate competitiveness. Total Quality Management & Business Excellence ISSN:, 17(7), 893– 911.

Lee, M., & Chang, T. (2010). Developing a Lean Design for Six Sigma through Supply Chain methodology. International Journal of Productivity and Quality Management, 6(4), 407–434.

Liker, J. K., & Morgan, J. M. (2006). The Toyota Way in Services: The Case of Lean Product Development. Academy of Management Perspectives, 20(2), 5–20.

Meredith, J. R. (1998). Building Operations Management Theory Through Case and Field Research. Journal of Operations Management, 16, 441–454.

(31)

Shah, R., & Ward, P. T. (2007). Defining and developing measures of lean production. Journal of Operations Management, 25, 785–805.

Smith, L. R. (2001). Six Sigma and the Evolution of Quality in Product Development. Six Sigma Forum Magazine, November, 28–35.

Sokovic, M., Pavletic, D., & Pipan, K. (2010). Quality Improvement Methodologies – PDCA Cycle, RADAR Matrix, DMAIC and DFSS. Journal of Achievements in Materials and Manufacturing Engineering, 43(1), 476–483.

Sousa, R., & Voss, C. A. (2008). Contingency research in operations management practices, 26, 697–713.

Womack, J. P., Jones, D. T., & Roos, D. (1990). The Machine that Changed the World, Rawson Associates/Macmillan Publishing Company, New York, NY.

(32)

Appendix I

Interview guide

About the researchers

In light of the “Master Thesis Project” two supply chain management students at the University of Groningen, Rutger van Ruiten and Andreas Stoikos perform a research project concerning the topic: DfSS projects in manufacturing industry.

Contact information: rutger8819@gmail.com, a.stoikos@student.rug.nl, Rutger 0646346296, Andreas 0611269409

Introduction and goals of the research

The interviewers seek to create more knowledge on DfSS projects in manufacturing industry. Two different angles are investigated. The use of Lean in combination with DfSS is investigated. Furthermore, four cases studies revealed information about the structure and the tools used within DfSS projects following IDOV or similar procedures.

Procedure of the interview

The interview will try to restrict itself to approximately 60 minutes. During this time, there are several questions that we would like to cover. Questions about the design process and questions related to the way the design process has been set up will be asked. After the interview, there is room for feedback and further questions on how the data will be processed. The information gathered will be transcribed and put into condensed information for the research. The transcriptions of the interview will be sent to the interviewee within one week after the interview and check if the interviewer interpreted everything correctly. If there are any questions before, during or after the interview, please contact us. (contact info)

Further notes

(33)

regarding the interview or protocol, feel free to contact us. Thank you for your agreeing to participate.

Basic information

QA.1 How long have you been: _______ at this organization? _______ in your present position?

What is your field of study? ____________________________________________ What is your highest degree? ___________________________________________

QA.2 What is your role in LSS? BB? GB? Champion? ______________________________ What has been your path within the company? How did you become a BB/GB?

Briefly describe your role (office, department, etc.) as it relates to DfSS project (if appropriate). How are you involved in the DfSS projects here?

How did you get involved?

QA.3 Are you working in project developing totally new products or are you working on the industrialization of the product?

- Do you follow the DIDOV in both NPD and industrialization?

- Do you have a supervisor in your role as BB or your regular function role in the design phase?

QA.4 How many projects did you carry out as GB/ BB? Did you carry out projects after certification?

How have you been educated towards BB/GB? How long the courses of GBs/BBs do they take?

QB.1 Are you working in a project just right now? In which phase? What is the kind of product you are working on? Only shavers?

Before going to stages,

QB.2 How are projects selected and the allocation of BBs take place? How was the planning of the project? How did it take in practice?

- Can you give us an impression about the length of the different Stages?

We have received a copy of this information. Do you recognize it?We have observed many tools and techniques here:

(34)

Define stage:

QB.6 What are the reasons behind separation of the Define and Identify stage?

QB.7 What is meant by Current State, Desired state, process-product map built in the 1st

block (business need identified)?

QB.8 Could you please describe the MGP?

QB.9 How important is that tool in order to proceed to the next block?

QB.10 How do SIPOC help in doing on functional breakdown/ project funnel?

QB.11 Why do you identify the customer needs after the project sign-off?

QB.12 What is needed to pass the tollgate from Define to Identify?

Identify stage:

Within this stage, it is really interesting how the deliverables are going to be met, according to the sequence of tools and techniques usage. Could you please describe how do you accomplish the tasks within the block “customer / user needs identified?

QB.13 Could you explain what is done QFD1? And why it is also called CTQ flowdown? QB.14 What does the QFD2 adds to QFD1?

QB.15 What is GR&R (for T&D)? What is the difference between industrial?

QB.16 How does the risk assessment of the predicted design capability (9th_{block) is related}

to the Identify stage?

We can recognize Design Dashboard as one of the last step in 3 stages (Identify-Design-Verify). QB.17 What are the reasons to build and use them and who is getting involved?

QB.18 What is needed to pass the tollgate from Identify to Design?

Design stage:

QB.19 Are all the tools/techniques mentioned used in all the projects? QB.20 How does Pugh matrix ensure to select the best design concept?

QB.21 How do you use the benchmarking technique? Do you have reference or a scheme? QB.22 What is the relationship among Historical regression, QFD2, simulations and DoE? QB.23 What do you mean by historical regression? Is that a special form of regression analysis? QB.24 What kind of DoE is that?

QB.25 Do you use more full factorial arrays or fractional factorial? QB.26 How complex the design matrix/array can be?

QB.27 Do you use software help you in DoE techniques? QB.28 Is DoE used in every project?

QB.29 Why there is a separation between FMEA1 and FMEA2?

(35)

QB.31 What kind is used in the Optimize?

QB.32 What is needed to pass the tollgate from Design to Optimize?

Optimize stage:

QB.33 What do you mean by Zst?

QB.34 What is the difference between Sensitivity Analysis1 and Sensitivity Analysis 2? QB.35 Are you often confronted to make optimizations on more than one CTQs at the same time?

QB.36 What is done, when you realize that you cannot meet the goals of CTQs?

QB.37 Do you recognize what is meant by Robust Design? Are you working on that often? QB.38 Do you use software in applying RD?

QB.39 Do you know the principles of Axiomatic Design? Do you use it?

QB.40 Could you please describe how do you verify the final mistake proofing? QB.41 What is needed to pass the tollgate from Optimize to Verify?

Verify stage:

QB.42 Are you often confronted with non-normality?

QB.43 Are you often confronted with Box Cox transformation? QB.44 Is your DfSS-team involved in this stage?

QB.45 Is the Monitor stage more a matter for management on a higher level?

QB.46 How do you value DIDOVM?

QB.47 What do you regard as really useful and what as less useful?

QB.48 What are the most inspiring elements on IDOV procedure and tools? QB.49 What kind of people giving permission to the next stage?

QB.50 Are there really similarities or differences in the use of tools- approach between NPD and Industrialization?

QB.51 How do you value of the DfSS project as a system?

Start part C DfSS and LPD

(36)

Q C4 Are you familiar with the Poka Yoke (fool proofing)? Do you think this is a useful technique?

Q C5 Are you familiar with VSM? How would that help you to make a project more successful?

Cross functional teams

Q C6 Which functions are included in a design project?

Q C7 Why are functions included or not? And in what stages?

Q C8 Do they take part in all meetings? Or is it varying from stage to stage? Q C9 How are these functions integrated in the different phases?

Q C10 What expertise’s do you think are relevant when putting a team together? Q C11 What functions do you think should be included in what stages of the project? Q C12 Are you familiar with concurrent engineering?

Information and knowledge

Q C13 How does company A train or educate its employees in using DfSS?

Q C14How does company A safeguard the sharing of information in a DfSS project? Q C15 How does company A retain/share knowledge from earlier and current projects?

Workload leveling and performance

Q C16 How does company A define its time planning?

Q C17 How does company A safeguard the most efficient project planning?

Q C18 If involving different functions how is the work load of each employee balanced? Q C19 How are performance metrics set and evaluated?

Q C20 How does company A try to reduce development costs of a product?

Q C21 How did your supervisors cope with the planning and reality? How can this be different? Q C22 Do you believe the current design projects can take less time?

(37)

Appendix II

Coding tree

DfSS tools QFD / CTQ flow down

“We use the v-model, basically we have a CTQ flowdown, on every level and as you have different levels on the v-model, in every level of the v-model there is the CTQ flowdown, and those CTQs flow-down to a deeper level.” “On CTQ flowdown you want to know how different parameters are related to each other and it is the same definition with QFD.” “The most important thing for the CTQ flowdown is to have cleared what are the end CTQs that we have to deliver.”

Design dashboard “There is a lot of data in the Dashboard, and all departments are using that.

The DD is the built up of all the CTQs.” “Will I meet on my requirements and in what level do I reach it. So you could use a dashboard, but you don't have a product yet it's probably all theoretical.”

“But also that you have the quality targets and production targets clear and of course customer needs, you have built up the Dashboard.”

FMEA “Normally in the Identify phase we do U-FMEA which is the user U-FMEA and that’s what that risk assessment is about.”

“So we have a user FMEA so what can go wrong at the consumer, you have the design FMEA what can go wrong in design and you have the process FMEA what can go wrong in the process.”

Cross functional teams

Alignment Sometimes it is hard to align this, because the engineers want to be free in the beginning of the project.

Yes, it is fine to take over their work partially as long as you align.

Regular meetings with the team help us to stay aligned.

(38)

“It is the most efficient way to develop a product. If you see our projects you see there is always 1 person of IND and 1 from engineering department, you have the production, technical support group and also the quality department.”

“You need the representatives from each department to check if you did everything right.”

Meetings “We have a com sell where we have all the team meetings at that place.”

“When you are in the project you have team meetings. Once or twice a week. Where you discuss what needs to be done and how far the current work is.”

Concurrent engineering

“We are using the experts from innovation when we have to challenge something when a process proves to be not capable for us.” “It makes it possible to develop faster, but it also gives a lot of friction. Because as a function developer you might want to change a part, but then at the production department they already have the molds in place. I cannot meet the new requirements.”

“Because the idea within Company A is that you pre-research that a function is feasible.” Knowledge and

information management

Training “BB’s are training the GB’s as part of becoming a GB. When we have a GB training, a BB is attached to coach the GB.”

“We train every engineer to become a GB. So everyone gets the DfSS training.”

“If you enter here depending on your function. First there is the training and an exam. Then you have a project and presentation and are a certified GB. From there on DfSS is connected to the way we work.”

“But everyone here at Drachten is instructed at the DfSS. When I did the training we had people from all places in the factory.”

Same language “The DfSS training creates an understanding of the whole project and provides a common language.”

(39)

“This training is useful for everyone to speak the same language.”

Information database “So one the things is that you have to describe the learnings and put them into a database.”

“At the end of the DfSS project a poster is made, these are stored in a database.”

“PLM system is quite broad, it is basically a system where all the information of a product can be found. You can work together on the same product.”

Learnings “These learnings can all be accessed for future learning.”

“Every project ends with learnings. You have to evaluate it. In our SWI it is standard to check learnings of previous projects.”

Meetings “It is planning. It provides clarity what needs to be done and show if we are on track” “The planning can always be looked into on our SharePoint. And we have a com sell, where we can see the road map.”

“It should be visible on the com sell board. Each project has their own com sell board.” Workload leveling

and performance

Lean planning “We call it Lean scheduling, it is a decision based planning. So it is not planning the activities, but rather what decisions do I need to make.”

“We put a team together and make a Lean planning. This is a decision based planning.” “What we do, we use Lean scheduling as a planning tool.

“For that we are using Lean scheduling as a method.

Milestones “Those milestones are related to the phases, because, but there are overlapping things.” “Level 1 planning is milestones, in week X we have to deliver the new design.”

“At a very high level you have the milestones on what you want to do, on the level 1 you see what decisions you have to make to pass the milestone.”

“It starts at level 1, what are the milestones, level 1 is what kind of decisions are you going to make within the milestones.”

Work packages “Then the work packages at the 2nd_level”

(40)

“Level 2 is the certain work packages that have to be done in a certain number of weeks.” “The work packages can be divided in different tasks.”

Weekly (personal) planning

“Level 3 is with post it’s telling what person has to do what this week.”

“On the last level, you have the activities to get those work packages done.”

Workload “Each task is posted, then we see how much work everybody has. If help is needed, other colleagues can help to balance the work load.” “You can visualize your workload by assigning colors to it. Red meaning to much work, yellow just enough and green being ready for more work.”

“The team guards the workload of the employees, if it goes wrong they come at me. Asking me for more resources.”

“We use that tool (Lean planning) to manage the work load for people. You can steer it at least a little bit by using Lean scheduling on level 3.”

SWI “We have now SWI, we notice everything goes quite smoothly. And discuss if we can improve some things in the SWI. It is much smoother than in the past.”

Lean Six Sigma in New Product Development Lean Product Development combined with DfSS