MSc Thesis Technology Management
Requirements Engineering at Philips Consumer Lifestyle IT Shaving
Cross-functional integration of product development teams and requirements development using UML Abstract:
In product development projects, requirements engineering ensures a solid translation from customer wishes into product specifications. This research focused on the optimization of requirements engineering to improve the predictability and quality of product development. To reach this goal, the main focus of this study has been on cross-discipline and functional alignment of project team members and the development of a UML-based requirements engineering method to reduce cost of non-quality and to minimalize time to market of product development projects at Philips Consumer Lifestyle Innovation Team Shaving.
Author:
Sjoerd E.B. Vleugel, BSc Julianalaan 66c
8932AD Leeuwarden Tel. 06-15609272
V1.9 public 27/05/2013
Supervisors University of Groningen: Dr. A.J.J. Braaksma
Dr. W.M.C. Van Wezel
Supervisors Philips Consumer Lifestyle Drachten: Ing. A. Kuijper
Document approved:
2
Foreword
Process
In this thesis I describe the analysis of one of the key processes enabling efficient and effective product development at Philips Consumer Lifestyle Innovation Team Shaving. Requirements engineering ensures a solid translation from customer wishes into product specifications. In order to identify improvement areas in this process, I first collected a true understanding of the organization and compared this with best practices in the industry, found in literature. It was my observation that Philips could be considered a benchmark and thus innovative solutions not yet available or given in literature were required to solve the challenges faced by the organization. Therefore a guided step by step process was needed to bring the Philips way of working to the next level. To achieve this, I executed thorough root cause analysis to identify the relevant improvement opportunities. In order to maintain a broad view on the problems at hand I continuously involved a large stakeholder base and debriefed those stakeholders several times to ensure alignment and continued interest in the subject. This helped to keep the priority and focus of the management team and other stakeholders on requirements engineering and my project. The challenge was to determine and accurately model the relation between the key performance indicators of the product development process and the requirements engineering process as well as coming up with improvement principles that could actually be put to use in the organization. To achieve this, I combined several fields of literature, best practices from other product development disciplines and insights from the organization to come to improvement proposals that lead to a reduction of cost of non-quality and time to market of product development projects.
Acknowledgements
This thesis is the result of an eight month intensive process of research at Philips Consumer Lifestyle Innovation Team Shaving, which I found to be exhilarating, highly educative and most of all very enjoyable. I would like to take this opportunity to thank my supervisors of the University of Groningen, Jan Braaksma and Wout van Wezel, for guiding me through this process and most of all keeping involved in my project with relentless enthusiasm. From the Philips community I would first like to thank my graduate internship supervisor André Kuijper for introducing me to Philips, the rich company culture within IT Shaving as well as taking time for deep discussions on this interesting topic. Secondly I would like to thank Richard Müller for taking the time to give feedback on my thesis and challenging me to go the extra mile. Thirdly I would like to thank Suzanne van Egmond and Manish Kumar Singh for their expressed trust and confidence in my ability to perform this task and their support along the process. Last but not least I would like to thank external experts Patric Wender, Huib van Nieuwenhuizen and Chris de Vries for their support and expertise.
Yours sincerely,
3
Management Summary
Background
Philips Consumer Lifestyle Management Team has set targets for IT Shaving of 25% less Time To Market and 10% reduction of Cost of Non-Quality to be reached by mid-term 2013. Judging by the IPD metrics for efficiency and effectiveness and the performance of the three baseline IPD projects Thor, Mpire and SR3, the throughput time and field call rate figures are too high. As these baseline projects represent the current way of working at IT Shaving, the IPD process has to be revised in order to improve the Throughput Time and Cost of Non-Quality to comply with CL targets.
Scope
This thesis focused on the requirements engineering process as it has a major influence on IPD outcome metrics. In the thorough root cause analysis it appeared that multiple key root causes could be distinguished that influenced high throughput time and field call rate figures. On a high aggregation level the scope of this research was on the variable cross-functional teamwork, as it influences IPD outcome metrics in general. On a lower aggregation level the research scope included the variable environment analysis, as the environment is the source of all requirements a product has to meet. Analysis of the environments of a product was found to be a key step in the requirements development process. Conclusion of root cause analysis
- A lack of cross-functional integration between team members influences the requirements development in the startup phase as well as in the industrialization phase of IPDs. This results in an increased Time to Market, or throughput time of IPDs.
- An ineffective environment analysis during IPDs influences Cost of Non-Quality. This is caused by a lack of functional analysis during the development of the product as well as a lack of functional analysis of the defect products.
Improvement design principles
Cross-functional integration
To reduce the throughput time of IPDs the cross-functional integration of IPD teams should be improved. First the superordinate identity of the team should be improved, which is the level to which team members identify themselves with the team instead of their functional area as well as perceiving a stake in the success of a team. This can be achieved through devising a reward system based on the project outcome instead of functional performance. Furthermore, the team longevity should be extended through having teams run a limited number of consecutive IPDs in the same composition before being disassembled.
4 Thirdly, the organizational context should enable the improvement of cross-functional integration of IPD teams. Therefore, champion support from senior management to individual IPD projects should be stimulated, as well as the promotion of job rotation between functional departments.
Finally a specific improvement on the integration of Marketing into the project team would entail the implementation of the proposed new commercial brief template and rigorous gatekeeping at VPD milestone on the quality of the commercial brief. This would enable better integration of commercial requirements and input into the product development process, improving the time to market of projects.
Ineffective environment analysis
To decrease the Cost of Non-Quality in the market the ineffective environment analysis performed in IPDs should be addressed. To accomplish this, engineers and quality engineers should be trained in the functional analysis and breakdown of products into requirement structures. Training in the Unified Modeling Language should prove helpful in this matter. Functional analysis and breakdown is essential in analyzing the environment of products and therefore a key step in developing products first time right. To help the continuous improvement of products and therefore the reduction of Cost of Non-Quality, defects occurring in the market place should be analyzed using UML and functional analysis.
Cost/benefit
Implementing the proposed design principles would cost considerable effort from multiple departments within Philips Consumer Lifestyle. Determining the exact cost of an extensive implementation is not possible, however with regard to the cross-functional integration the largest investments would include an overhaul of the reward structures currently in place as well as the planning of employment resources for projects. With regard to increasing the effectiveness of the environment analysis performed in projects the implementation is currently being done with no expected extra resources needed.
Determining the exact benefits of the proposed design principles is also not straightforward. With regard to the improvement of cross-functional integration the influence on the performance of product development projects was found to be positive in literature. Therefore one can expect performance improvement at IT Shaving when implemented. With regard to improving the effectiveness of the environment analysis performed in projects, hard Cost of Non-Quality reduction figures cannot be given. However, as the example of the ‘retaining ring’ defect illustrate, the costs of an ineffective environment analysis outweighs the cost of improvement implementation by far.
Recommendations
I recommend improving the cross-functional integration of teams by redesigning the reward structure in projects first. This improvement can be done without major complications in the current projects. The implementation of employment resources for projects is a more complicated process and therefore needs a more elaborate implementation plan. The other recommendations given on cross-functional integration are less complicated and resource demanding and can be implemented later.
5
Content
1. Introduction ...7
1.1 Relevance and initial complaint ... 7
1.2 Objective ... 8
1.3 Research questions ... 8
1.4 Methodology ... 9
2. Literature study ... 10
2.1 Measuring NPD projects ... 10
2.2 Success factors in NPD projects ... 10
2.3 Requirements engineering ... 11
2.4 Cross-functional teamwork ... 14
3. Case study ... 17
2.1 Case study design ... 17
2.2 Innovation Team Shaving introduction ... 19
3.3 Problem identification ... 23
3.4 Problem analysis... 28
3.5 Case study conclusion ... 45
4. Improvement Principles ... 46
4.1 Design Principle theory ... 46
4.3 Design Principles on cross functional teamwork ... 47
4.4 Design Principles on specific requirements engineering practices ... 50
5. Conclusion and recommendations ... 57
6. Limitations, generalizability and future research ... 58
7. Bibliography ... 60
APPENDIX A: case study protocol ... 65
APPENDIX B: Supplement explanation to the causal model: ... 76
6 Table of abbreviations:
AA Assignment Agreed
CAPEX Capital Expenditure
CL Consumer Lifestyle
CMM Commercial Market Manager
CR Commercial Release
DOV Diagnose Ontwerp Verandering
DQD Development Quality Department
ESE Electrical and Software Engineering
FMEA Failure Mode Effect Analysis
FOS First Official Sample
FOT First Out of Tools
I&D Innovation & Development
IPC Innovation Personal Care (includes Vitalight, Grooming and Shaving)
IPD Integrated Product Development
IR Industrial Release
IT Innovation Team
LCM Lifecycle Management
MDD Mechanical Development Department
NPD New product Development
NPD New Product Development
PB Project Brief
PC Prototype Consolidated
PMO Project Management Office
PPC Project Plan Consolidated
PRC Product Research Centre
PV Product Validated
R&D Research & Development
RD Requirements Development
RE Requirements Engineering
RM Requirements Management
TCP Technical change proposal
TIC Technology Innovation Cost
7
1. Introduction
In this chapter, first the relevance of this thesis will be depicted from a literature perspective as well as a practical standpoint and will include the initial complaint that initiated this research. Secondly, the objective will explain the goal of the thesis after which the research questions will be stated. Thirdly, the research methodology will be depicted in an overview of the research phases and the generated output. Finally a review on relevant literature will give an introduction to the literature field.
1.1 Relevance and initial complaint
In today’s global and competitive business environment, companies are under pressure to perform better in terms of low-time, high-quality and high value output that can provide competitive advantage for the organization (Baxter et al, 2008). The importance of new product development (NPD) has grown dramatically over the last few decades (Schilling & Hill, 1998). New product development has become critical to the growth and prosperity of firms (Rogers, Ghauri & Pawar, 2005). Therefore there has been great interest from both researchers as well as practioners on finding new ways to optimize the new product development process (Schilling & Hill, 1998).
As a global player in the consumer electrics market, Philips Consumer Lifestyle has several Innovation & Development sites which run new product development projects. In the highly competitive market of electric shaving, Philips Innovation Team Shaving is on a continuous search for improving their NPD processes to improve the success of their products and therefore the results of the company. The IT-Shaving Management Team (MT) considers the requirements engineering process to be the backbone of NPD projects. Requirements engineering is the process of translating vague consumer requirements to specific and detailed requirements to enable the development of a product design. The IT-Shaving Management Team (MT) feels that when this process is not managed properly, the developed end products do not satisfy crucial requirements of important stakeholders. Therefore this process should run flawlessly. According to several stakeholders in the MT, the malfunctioning requirements engineering process is one of the causes of problems related to the output of the NPD projects.
According to the MT, effects of the malfunctioning requirements engineering process are the following: - The MT has noticed an increase of ineffectiveness in the product development process:
o Products are made according to customer requirements set in the development process. However, customers are increasingly returning products as their needs are seemingly not fulfilled.
o Increasing quantities of products made according to specifications that meet requirements are sent back from the market due to technical defects.
o In the development stage, products are developed according to requirements set at certain moments in the project. Requirements added in later stages of the project put the introduction timing of developed products at risk, jeopardizing high-volume business deals with wholesalers.
- The MT has noticed an increase of inefficiency in the product development process:
8 User IPD process Target output: Develop and produce effective shaving products in an efficient way Quality problems Unsatisfied customers Timing at risk Peak workload MT initial complaint: Stakeholder Requirements Business Production Legislation Resources Budget (€) Time (FTE)
Figure 1: Philips IT Shaving as a system
Taking a step back from the initial complaint from the MT and using a systems thinking approach (De Leeuw, 1994), the IPD process can be seen as a system that converts input to output. The function of the IPD process is to convert stakeholder requirements and resources to effective shaving products in an efficient way. To define the system boundary, the NPD process is regarded for now as a black box which produces output that is not satisfactory, as seen in Figure 1.
1.2 Objective
The foremost goal of this thesis is to improve the new product development process at Philips Consumer Lifestyle Innovation Team Shaving. As mentioned in Figure 1, the new product development process, or IPD (Integrated Product Development) in Philips terms1, can be regarded as a system which does not produce output according to targets of the management team. The efficiency of the IPD projects as well as the effectiveness of the products developed is not satisfactory, as the management team targets for mid-term 2013 are not yet met.
The objective of this thesis is to analyze the IPD process, find root causes of the non-conformity of output to the targets and give solution principles to improve this output.
1.3 Research questions
To reach the objective of this thesis, the following research question and sub-questions were formulated:
Main research question: How should Philips Innovation Team-Shaving improve the output of the IPDs to
comply with efficiency and effectiveness targets?
Sub-question 1: What root causes of inefficiency and ineffectiveness of the requirements engineering
process can be determined?
Sub-question 2: How can these root causes be mitigated in order to improve the output of the IPD
process
1 When referencing to literature the term NPD will be used in this thesis. When referring to the specific Philips
9
1.4 Methodology
1.4.1 Research phases and output
The objective of this research is to improve the output of the IPD process at Philips IT Shaving. The methodology to reach this goal has been based on the DOV2 methodology (De Leeuw, 1994). This methodology comprises several phases as shown in Figure 2:
Functional/ instrumental analysis Context orientation Initial complaint Stakeholder analysis Empirical research results Empirical analysis Conceptual causal analysis Empirical causal model Formulate solutions Root cause analysis
Process redesign Implementation of design Measure improvement 1: Problem identification 2: Problem analysis 3: Solution design
Research goal Research objectives Research results
D ia gn o si s D es ig n Controlled situation 4: implementation Control C h an ge D ia gn o si s Goal/perception/ reality check
Figure 2: DOV-methodology, based on (De Leeuw, 1994; Prins, 2008; Wu, 2010)
The problem identification phase started with the initial complaint, after which the context of the problem was analyzed. After depicting the functional problem of the problem owner, other stakeholders within the chosen system boundary were interviewed to check the legitimacy of the problem. Multiple problems with respect to the output of the system were selected, after establishing that the problems exist in reality, were not due to unrealistic goal-setting or perception, and stakeholders were not unambiguous about system definition or system goals. After setting the research goal, the problem analysis phase focused on finding possible root causes of the problem and validating whether these root cause variables were legitimate through triangulation of data. This yielded the research objectives. The design phase addressed the research objectives through redesigns of the system that causes the functional problem. The implementation phase was not part of this thesis due to limited resources.
2
10
2. Literature study
This chapter will show literature aimed at explaining the context of various aspects of this research. First the criteria on which NPD success is defined are determined, after which success factors in obtaining this success are determined. Then these success factors are explained.
2.1 Measuring NPD projects
Rogers, Ghauri & Pawar (2005) noted that new product development has become critical to the growth and future prosperity of organizations. Schilling & Hill (1998) even state that new product development (NPD) is the single most important factor driving firm success or failure. Therefore, measuring the performance of the NPD process has become a widely researched topic in literature. In their work Rogers, Ghauri & Pawar (2005) have identified the following NPD metrics to be amongst the most used in practice:
- Total cost of project (Cost) - Lead time to market (Time) - Product failure rates (Quality)
Schilling & Hill (1998) indicate that in order to recoup development costs (Cost) and make an economic return, NPDs must meet two critical objectives: minimize time-to-market (Time), and maximize the fit between customer requirements and product characteristics (Quality).
2.2 Success factors in NPD projects
11
2.3 Requirements engineering
A product development process is a sequence of steps or activities which an enterprise employs to conceive, design, and commercialize a product (Ulrich & Eppinger, 2008). The generic phases of the process are depicted in Figure 3, in which the market and consumer trends gathered in phase 0 are captured to summarize the wishes of customer segments and market chances. Using this summary, various product scenarios are developed that are further refined through the following phases to turn out the final product at production ramp-up.
To define what the product should look like, what it should do and how it should interact with its environment, requirements are defined. Requirements engineering is an iterative process, closely linked with the development phases in the product development process (Parviainen & Tihinen, 2007).
Following the phases in the product development process from concepts down to detailed design, different levels of requirements can be differentiated. For example, requirements for a system like an electric car could be as follows:
- Level 0: Stakeholder requirements
All stakeholders in the project have requirements, for instance the end consumer could state; “I want an electric car that I can drive to and from work on the same day while carpooling with my colleagues, without having to charge it at work”.
- Level 1: System requirements
The developed system has to comply to the level 0 requirements: “The system MUST be able to carry 4 persons for 200 km with an average speed of 100 km/h on one charge” - Level 2: Module requirements
The module requirements have to deliver the right performance in order to fulfill requirements of level 1: “The drivetrain of the system MUST be able to deliver 30 KW for 2 hours”
- Level 3: Part requirements
The part requirements have to deliver the right performance to fulfill requirements of level 2: “The battery-pack of the system MUST have a capacity of 60 KWh”
12 Requirements engineering can be divided into two main groups of activities, requirements development and requirements management (Parviainen & Tihinen, 2007).
Requirements are gathered from multiple sources in the process of requirements development. As the overall goal of product development is to satisfy customer needs and wishes as well as meeting enterprise strategy, requirements are sourced from market trends and consumers as well as internal stakeholders like marketing, mechanical/electronic/software design, sales support, etc. (Stechert & Franke, 2009). After the requirements from the stakeholders are gathered, the level 0 requirements are analyzed on technical feasibility and cost-benefit and trade-off analyses are done. The allocation of level 0 requirements to level 1 (system) defines the system architecture and modules. The level 1 system requirements are assigned to specific modules according to the overall architecture plan of the system, after which level 3 part requirements are developed. This process is called the flow-down of requirements (Parviainen & Tihinen, 2007), as illustrated by the previous electric car example.
Requirements management is part of the continuous activities of the requirement engineering process. Requirements management activities include the change control of requirements, documenting and traceability, verification and validation. As requirements are prone to change as the product is developed, change control of requirements is essential to assess the impact and to track costs of the proposed change (Sommerville & Sawyer, 1997). To be able to assess the impact of changing requirements, documentation and traceability is needed. Through documenting requirements and linking the several levels of requirements from level 0 stakeholder requirements to level 3 part requirements, the impact of changes in level 3 part requirements can be traced back to level 0 stakeholder requirements, which is called traceability. For instance in the example of the electric car, a drastic decrease in the capacity of the battery pack (level 3) could have severe impact on the level 0 requirement of being able to go to and from work without charging. Requirements verification and validation takes place in a later phase of product development, making sure that the requirements will yield a product that performs in a way it was intended.
Environment analysis
Requirements are a language for modeling the intended behavior of a product (Sommerville & Sawyer). Furthermore, requirements are descriptions of the desired solution to a design problem. (Wang & Zeng, 2006) In engineering design, just as in all other design problems, the efficient, precise, and complete specification of requirements is critical if designers are to deliver a quality product within a reasonable range of cost and time (Wang & Zeng, 2006). Chen & Zeng (2006) determined that the product environment is the source of all product requirements: requirements can be defined by listing
Requirements Development: Requirements Elicitation Requirements Flowdown Requirements Management: Change management Traceability Validation/Verification
Requirements
Engineering
13 environment components with which a product interacts and how the product should deal with this interaction.
Modern systematic design can be characterized along four underlying principles: hierarchical decomposition, systematic variation, satisficing and discursiveness. This first task, hierarchical decomposition is the breakup of the design task into sub problems that can be tackled by individual or small groups of engineers. The primary aim of this decomposition is to be able to assign tasks to team members and identify subtasks for which a solution already exists. This decomposition is often employed through some form of functional analysis in which the team lists both the required inputs and outputs of the new product. Its overall function is then decomposed into a block diagram of sub functions, together achieving the complete required functionality (Leenders, Van Engelen, & Kratzer, 2007).
14
2.4 Cross-functional teamwork
As displayed in the new product development process in Figure 3, various scenarios are developed in the beginning of the project. This is done to explore the various concepts and their fit with the project goals in terms of feasibility and profitability. Through teamwork between the various functional groups represented in the project team, the number of scenarios is reduced to eventually come to a single scenario that is developed further in the project. Abstractly put, this process of determining and choosing scenarios during the fuzzy front-end is information processing to reduce uncertainty in the project (Souder & Moenaert, 1992; Verworn, Herstatt, & Nagahira, 2008).
To reduce uncertainties, and therefore risks, in NPD projects, information has to be gathered and processed. (Souder & Moenaert, 1992; Verworn, Herstatt, & Nagahira, 2008) This information is sourced and processed by various stakeholders in the project team, which requires a close cooperation between those stakeholders, often being Marketing, Design and R&D. It is established in literature that this cooperation between those stakeholders in product development processes often proves to be hard (Nakata & Im, 2010; Sethi, 2000; Shaw, Shaw, & Enke, 2004; Song, Kawakami, & Stringfellow, 2010). Therefore, improving the teamwork of NPD stakeholders and the interaction (interface) between Marketing, Design and R&D should reduce uncertainty earlier in the NPD. In literature this relation between improved teamwork and the performance of the product development process is embedded strongly (Nakata & Im, 2010; Sethi, 2000; Song, Kawakami, & Stringfellow, 2010) In these previous works, various variables are indicated to influence this Marketing-Design-R&D interface and therefore product development performance. Based on this literature a framework was devised. In Figure 5 the Marketing-Design-R&D interface is dependent of three distinct constructs; superordinate identity, social cohesion and organizational context.
Superordinate identity
Social cohesion NPD Teamwork
performance Marketing-Design-R&D interface Organizational context
15 Superordinate identity: In the context of a cross-functional product development team, superordinate identity refers to the extent to which members identify with the team (rather than merely with their functional area) and perceive a stake in the success of the team. This construct is positively related to product development performance (Sethi, 2000). High superordinate identity enhances the perception of intrateam similarities and leads to psychological acceptance of members from other functional areas and their work methods, thereby reducing the adverse effect of interfunctional biases and stereotypes. A feeling of psychological ownership of the project arises among team members, which enhances cooperative behaviors and motivation (Sethi, Smith, & Park, 2001). The integration of functional perspectives and therefore the Marketing-Design-R&D-interface is enhanced by these processes. According to the research of Sethi (2000), superordinate identity is dependent on outcome interdependence, team autonomy and team longevity. Outcome interdependence is the degree to which team members’ responsibility, accountability, evaluation and rewards are linked to the project rather than to their respective functional areas/tasks. Team autonomy is the extent to which the team has the freedom to make its own project-related decisions and conduct its work the way team members deem fit, without interference from senior managers outside the team. Team longevity refers to the duration for which team members worked together to complete the project.
Social Cohesion: Sethi (2000) clearly states that superordinate identity is not the same as social cohesion, as the latter represents the affective component of the member-team relationship. As Chang & Bordia (2001) indicated, social cohesion does have a positive influence on group performance. Nakata and Im (2010) proved that the social cohesion construct is a complementary factor to superordinate identity in cross-functional integration of the Marketing-Design-R&D interface and therefore product development performance. However they do not include factors that influence social cohesion in product development teams. Hauptman & Hirji (2002) as well as Shaw, Shaw & Enke (2004) found that there are common barriers in the integration of cross-functional teams. These barriers include differences in personality, culture
and language as well as the level of comprehension of each other’s jobs. Holland, Gaston, & Gomes
(2000) found that frequent and genuine internal communication positively influences social cohesion. Therefore I argue that these variables influence the construct social cohesion specifically in the Marketing-Design-R&D interface.
Figure 6: Superordinate identity construct
Superordinate identity Outcome interdependance Team autonomy Team longevity
16 Organizational context: Holland, Gaston, & Gomes (2000) concluded that there are several critical succesfactors in the organizational context for cross-functional teamwork in product development: Stating a clear mission for a project by senior management gives the product team focus and a common goal. Senior managers that act as project champions and maintain this commitment help to improve the crossfunctional integration and therefore the teamwork performance. Team co-location is an important factor in communication and therefore increased teamwork. However, this factor is discribed in older, pre-internet research, which begs the question whether and how it is affected by modern digital communication structures. Furthermore, Sethi (2000) rules out that physical proximity stimulates superordinate identity and while that does not implicate that physical proximity has no influence on teamwork, it does makes one wonder what exactly it influences within team performance. Knowledge transfer between team members is of vital importance as the whole fuzzy front-end of any project is an iterative process of generating, sharing and processing information. Hauptman & Hirji (2002) found that job rotation policies are positively related to cross-functional group integration.
Stimulating the integration of Marketing, Design and R&D stakeholders in NPD teams through improving the superordinate identity and social cohesion of the group and providing the appropriate organizational context could improve the team performance.This would improve the efficiency of the requirements development process and therefore decrease the time spent in the fuzzy front-end of the project, allowing for a focus on fewer scenarios that can be better developed. Furthermore, a better integration of stakeholders and therefore better uncertainty reduction could lead to better effectiveness of the project, as empirically proven by Verworn, Herstatt, & Nagahira (2008).
Organizational context Knowledge transfer Clear mission Job rotation policies Senior champions Team co-location
17
3. Case study
This chapter will describe the case study performed at Philips Consumer Lifestyle Innovation Team Shaving. In the first paragraph the case study design will be explained. In the second paragraph Innovation Team Shaving and its organizational context will be introduced. In the third paragraph the exact problem that initiated this research will be determined. The fourth paragraph will show the problem analysis, after which the fifth paragraph will conclude on the research questions.
The following paragraph will first explain the rationale for the choice to perform a case study at IT shaving, after which the measures taken to ensure robustness of the case study design will be clarified. Then considerations on the selection of cases for the embedded case study design will be explained.
2.1 Case study design
To design solutions for the problems within the IPD process of Philips a case study was performed. A case study is an empirical inquiry that investigates a contemporary phenomenon in depth and within its real-life context, and is useful especially when the boundaries between phenomenon and context are not clearly evident (Yin, 2009). Furthermore, case studies are the preferred strategy when ‘how’ and ‘why’ questions are posed and the investigator has little control over events (Yin, 2009). Boundaries between the processes in the IPD and its context are blurred and intertwined, and the questions that were posed in this research were mainly how and why related. Furthermore, the researcher has little control over events taking place within the NPD process. Therefore a case study seemed appropriate. This case study was set up using an embedded case study design (Yin, 2009) meaning that multiple instances of validation were sought, using projects in the same environment. The rationale for this choice was that a broad selection of projects would yield a less specific analysis, therefore increasing the generalizability of solution principles towards IT Shaving, Innovation Personal Care Drachten (which includes IT Vitalight, IT Grooming and IT Shaving) as well as NPD companies in general.
2.1.1 Robustness
To ensure a robust research design, four quality criteria as described by Yin (2009), have been used: Construct validity has been established through validating the problem statement and the causal model with its constructs through several presentations and discussions with multiple stakeholders as well as having the draft case study report reviewed by multiple stakeholders (Yin, 2009). As a final measure to ensure construct validity the final causal model has been validated in a session with key stakeholders to conclude on the analysis of the problem through the causal model.
18 External validity has been established through the embedded case study design which has multiple units of analysis and therefore improves the analytical generalization3 towards the system that is researched, namely Philips CL and the IPD process. The generalizability towards the world outside this researched system has been safeguarded through choosing a high aggregation-level approach towards the formulation of both the problem statement as well as the solution designs. Contingencies that influence the solution designs have been denoted which indicate the aspects to be aware of when generalizing the findings of this research towards the world outside the researched system. Furthermore, for a specific solution four external experts have validated the design principles suggested in this thesis.
Reliability has been established through first developing the case study protocol (appendix A), as well as having multiple sources of data. In this research the following data sources have been used, according with the sources of data pointed out by Yin (2009): documentation, archival records, interviews and direct observation.
2.1.2 Case selection
As the choice was made for an embedded case-study design, multiple cases should be chosen on predefined criteria. In the initial complaint of the Management Team it appeared that the IPD output on effectiveness and efficiency was not satisfactory. Common product development metrics for effectiveness and efficiency were found in the literature study; cost, quality and time. The selection of cases should occur on theoretical grounds, driven by considerations about independent variables or dependent variables (Van Aken, Berends, & Van der Bij, 2007). In figure 9 the IPD process as a black box and its output is displayed. The variables Cost, Time and Quality are dependent on the independent variable IPD process, and thus render the criteria to select cases. As the goal of the case selection is to improve the generalizability through heterogeneity, the degree of innovation and the price-range could also be considered selection criterions as these are also dependent variables of the …. Figure 9: Causal model I IPD process and differentiate the projects.
3 Note that this is not statistical generalization (Yin, 2009) and therefore the number of cases in the embedded
case study design is irrelevant related to statistical terms like ‘sample size’.
Problem:
output of IPD not conforming to targets
Cost
Time
Quality
19 Table 1: Selection of cases
Stakeholders recommended analyzing three projects, named Thor, Mpire and SR3, on grounds of availability of data and the equality of the IPD processes used in the projects. However, to check whether the suggested projects are heterogenic and therefore the findings based up these projects can be generalized to the IPD process in general, the selection criterions were applied in table 1.
Conclusion
As table 1 shows, the majority of the criterions judge the projects to be different, rendering the cases heterogenic. This will increase the generalizability of the improvements found in this research and legitimizes using projects Thor, Mpire and SR3 for the problem analysis.
2.2 Innovation Team Shaving introduction
This paragraph will first introduce Philips Consumer Lifestyle, its mission & vision and customer strategy. The global shaver market and its competitive environment will be introduced. After this the organization of the Innovation Team Shaving will be described. The development methodology for these products is then explained in general, including requirements engineering and management processes.
2.2.1 Mission/vision
The Innovation Team shaving is responsible for the development of all shavers that Philips Consumer Lifestyle (CL) brings to the world markets. The mission of Philips CL is to reach 3-6% sales growth and 8-10% EBITA for mid-term 2013. This is accomplished by, amongst other measures, innovating with 25% faster Time-To-Market and reducing cost of non-quality by 10%.
3.2.2 Customer Strategy
Philips CL has a customer strategy that can best be defined as product leadership. According to (Treacy & Wiersema, 1993) this strategy incorporates the production of a steady stream of state-of-the-art products through creativity and innovation, commercializing innovation quickly and emphasizing speed in the development process. All three elements can be found in the setup and strategy of the IPD and IT Shaving. IT Shaving serves all markets in which Philips CL is active, however it has divided the global market for shavers into BMC’s or Business Market Combinations. The Business Market Combination structure was introduced in 2011 as an initiative to enable sustainable growth through a specifically targeted product portfolio (Philips, 2012) Before this structure was implemented the product portfolio was less targeted at specific markets. This one-size-fits-all approach has been abandoned to introduce a more tailored approach to specific clients as well as specific customer groups. This renders the strategy of Philips CL a mix between product leadership and customer intimacy through segmenting and targeting markets precisely, thus tailoring to match exactly the demands of those niches (Treacy & Wiersema, 1993). An example of this customer intimacy and product leadership mix is an upcoming
Thor Mpire SR3
Cost Low Medium High
Time Low High High
Quality High Low Medium
Innovation degree
Low Medium High
Price range
Low-end Mid-end High-end
Confidential information
20 shaver product targeted at the Afro-American population of the US, which has completely different skin and beard characteristics than the average Caucasian US customer. This difference in customer characteristics calls for a modified and tailored technical design. The product is both innovative and state-of-the-art while also being targeted at a specific niche in a local market.
3.2.3 Competitive environment
Competition within the electric male grooming market is fierce, Braun and Panasonic being the key competitors of Philips CL. As seen in Figure 10: Total Male Grooming market size, 31% of the total male shaving market is taken up by electric shavers, in which Philips is market leader by covering 14%, representing a total value of €1.87 billion Euro.
3.2.4 Typology of organization:
Innovation Team (IT) Shaving is responsible for the development of all shavers sold by Philips CL worldwide. IT Shaving consists of multiple departments located at the innovation site Drachten. The electronic and mechanical departments as well as project management, product/consumer research center, product architecture, development quality, packaging and production departments are located at Drachten, while design and commercial departments are located in Amsterdam. Having high task interdependency as well as a grouping of job functions, this way of dividing IT Shaving into several departments can be classified as functional departmentalization (Hatch & Cunliffe, 2006). Furthermore, the organization has organizational structures of both mechanical and organic nature (Hatch & Cunliffe, 2006). The mechanical nature of the organizational structure can be seen in the clear hierarchy in the organization with a rank system in all departments with predefined tasks within IT Shaving. However, organic structures are also present in the organization as cross functional and cross departmental IPD projects and improvement projects are run parallel with the predefined tasks of each department. The organizational configuration of IT Shaving is a mix of both machine and professional bureaucracy (Mintzberg, 1980). Contingencies that fit with these archetypes of organizational structure can be noticed. For instance the key coordinating mechanism within IT Shaving; standardization of work, the functional grouping of employees, action-based planning, the high age and large size of the organization all point to a machine bureaucracy. Contingencies like a high level of employee training, a typical low formalization of behavior and a highly complex but relative stable environment are part of the professional bureaucracy typology. Therefore, the fit between the organizational configuration the and the contingencies present at IT Shaving seem to match.
Figure 10: Total Male Grooming market size 2013
Confidential information
Confidential information
21
3.2.5 Development methodology Philips
IT Shaving develops all electric shavers for Philips Consumer Lifestyle. The products are developed per project in low, mid and high ranges that form the differentiating products for each segment of the market. The level of innovation of the products of IT Shaving can be considered as incremental as the products provide new features, benefits and improvements to the existing technology in the existing market (Garcia & Calantone, 2002). The level of innovation is on average higher in the high-end range of products, with more innovational features being added than the low-end range. Product portfolio planning is done through product-technology roadmaps (Ulrich & Eppinger, 2008), which outline the product planning for a period of 3 to 5 years.
To develop new products, Philips has developed its own product development methodology; the Integrated Product Development (IPD), largely based on the stage-gate methodology of Cooper (1990) The IPD consists of phases, milestones and hard-gates, as displayed in Figure 11.
Figure 11: Philips IPD milestones and hard gates
The IPD is the process in which the product is developed from loose ideas and vague consumer wishes to an industrially produced end-product. In the starting phase of the IPD, commercial requirements for the product are gathered and agreed upon at the first hard gate in the IPD (VPD, or Value Proposition Debrief). These commercial requirements are then developed into product requirements and subsequent designs during the phase between the first and second gate (PPC, or Project Plan Committed). After the PC milestone (Prototype Consolidated) the tooling for mass production is ordered, after which the first production run will produce test-models to verify the product requirements and specifications. After the third hard gate (CR, or Commercial Release) the product is introduced into the market and the production ramp-up takes place.
22
Requirements Engineering at Philips IT Shaving
Requirements are descriptions of the desired solution to a design problem (Wang & Zeng, 2009). Furthermore, requirements are statements that identify a products’ operational, functional, or design characteristics or constraints, which are unambiguous, testable or measurable, and necessary for product acceptability by consumers or internal quality assurance guidelines (IEEE, 1999). In the IPD of Philips Shaving this dual function of requirements, which are used for development as well as testing (IEEE, 1999), is put into practice through the V-model as displayed in Figure 12. Requirements are gathered from stakeholders, both internal and external and put in the statement of need, at the top left of the V-model. These requirements are then translated in commercial requirements and CTQ’s (critical to quality requirements) which emphasize certain features and requirements from the product. The requirements then flow down into system requirements which describe the workings of the system at top level. The following level is the subsystem requirements which make up the modules of the system. The subsystem requirements are then translated into component requirements. Once the requirements of the product on all levels are set, the product is designed to match these requirements. To check whether the designs match the requirements, verification and validation on all levels of the V-model takes place. After validating the product against the highest level requirements, the product is accepted and introduced in the marketplace.
23
3.3 Problem identification
In this paragraph, the problems of IT Shaving that are in scope in this thesis are identified, using the methodology of De Leeuw (2000). The functional nature of the initial complaint will be verified using the tripteach of Haselhoff to determine the severity of the real problem. Then a stakeholder analysis determines which influential stakeholder perceive a functional problem and whether there is an agreement on the goals of the system. The goal/perception/reality analysis will provide a last check of the legitimacy of the problem, after which conclusions are drawn on the functional problem to adress in the problem analysis phase.
3.3.1 Functional/instrumental analysis:
The instrumental problem as defined by the management team in the initial complaints (paragraph 1.1), is that the requirements engineering process does not function well. However, a problem is functional when it affects the systems effectiveness (output related performance), efficiency (realizing right output with minimal resources) or usefulness (efficacy of the system) (Prins, 2008).
The functional problem of the stakeholders is that the output of the IPD process is not conforming targets and efficiency could be improved. The current way of working results, according to stakeholders, in increased cost of non-quality, possibly more unsatisfied customers and less efficiency during product development. The causes of this functional complaint should be investigated further to come to a fitting solution. To validate the legitimacy and severity of the functional complaint the triptych of Haselhoff (De Leeuw, 1994) was used.
3.3.2 IPD & Effectiveness:
Effectiveness can be defined as the ratio between the achieved results and the aspired results of the process (In 't Veld, Slatius, & In 't Veld, 2007). The current Philips way of measuring effectiveness is displayed by the FCR and NPS ratios.
Field Call Rate
Field Call Rate (FCR) is a quality metric that depicts the percentage of all produced products that are returned from the market to customer care centers due to complaints of the customer (Petkova, Sander, & Brombacher, 2000). FCR is a measure of effectiveness as the aspired result is a defect free product, while the achieved result is a product with defects, as displayed by the Field Call incidents. The FCR percentage of some products of the current generation of shavers is significantly higher than the FCR percentage of the previous generation of shavers, while targets set by upper management for improvement of FCR are
24 challenging as no shaver project has achieved this low level of cost of non-quality in the market.
Figure 13 shows the FCR for three products of the current generation shavers (SR3, Mpire and Thor) as well as the average FCR of the previous generation and the target FCR for 2015. It is clear that the FCR of both SR3 and Mpire is higher than the previous generation average FCR and the target of 2015, depicting the challenge for IT Shaving to develop shavers that are less plagued by defects in the market. Conclusion: based on the FCR metric, the IPD process is not effective.
Net Promoter Score
NPS or Net Promoter Score is another measurement of effectiveness of the IPD used within Philips Shaving. NPS is a metric for assessing the loyalty behavior of customers, measured by the single question “would you recommend this product to a friend” (Reichheld, 2003). Philips aspires to develop products that completely satisfy customers. NPS measures the actual level of satisfaction that is reached through the product proposition and therefore measures the effectiveness of developed products. Although the applicability of the NPS measurement is much debated in literature (Keiningham, Cooil, Andreassen, & Aksoy, 2007) (Hanson, 2011) it is the leading indicator used by Philips CL to measure the level of satisfaction of their customers with the products that are developed. The NPS is made up of three distinct categories of customers. Detractors, or customers that are so dissatisfied with a Philips shaver that they would actively discourage other people to buy the product. Passives, or customers that would not recommend nor discourage people to buy the product. Promoters, or customers that are very satisfied with the product and would recommend the product to other people. (Reichheld, 2003)
Table 2: NPS Shaving Europe
Table 2 shows no apparent decrease of the NPS4 between 2009 and 2012 and a decrease of detractors. The targets set for projects on NPS are to have a better NPS score on the key benefit than the predecessor product and the direct competition product. Over the recent range of fifteen developed shaver products, only two did not outperform the competition. All shaver products had a better NPS score than their predecessor. However, the challenge for Philips is to make products that satisfy customers in such a way that they become promoters in the NPS survey. Following the reasoning of Reichheld (2003), Philips management believes that a higher NPS will result in higher profit.
Conclusion: based on the NPS metric, the IPD process is effective.
4
25
3.3.3 IPD & Efficiency:
Efficiency can be defined as meeting the required output demands with as less resources as possible (In 't Veld, Slatius, & In 't Veld, 2007). The IPD project efficiency is determined through several measures: CAPEX or Capital expenditure is the budget reserved in the project for building moulds, production lines and other equipment to produce the product. This budget is set individually for each IPD project. At milestone PPC, the IPD team sets the PPC target budget which give estimations for the Business Department Amsterdam to build the business case for the project. In hindsight, the project spending on CAPEX is added to make the final budget spent number at the project end. Both the PPC target estimations and the actual spent budgets on CAPEX are displayed in Figure 14.
TIC or Technology Innovation Cost is the budget reserved in the project for developing the product and is spent on resources like manpower, prototyping and other expenses in the development stage. As with the CAPEX, the budget is estimated at milestone PPC and the actual spending of the budget is verified at the end of the project. Both numbers are displayed Figure 15 for the baseline projects.
FCP or Factory cost price is the net cost of the parts of the product. As with the other metrics, FCP is estimated at milestone PPC and verified at the project end. It is hard to draw straightforward conclusions from these figures. Judging from TIC and CAPEX figures, SR3 project was either quite efficient in spending or the budget estimation at PPC was not reliable, according to the MT controller. Due to the unreliable forecasting of projects, the MT could decide to set targets lower than the estimation given by project managers at PPC by subtracting a part of the deviations in estimations and actuals from the past, as IPD teams may estimate budgets higher than necessary. Judging projects by FCP,
Figure 14: CAPEX budgets
Figure 15: TIC budgets
26 or factory cost price, is also not straightforward, as the FCP given here is an average of the project FCP. Project Thor is a shaver project which includes multiple types of the appliance, which all have a different FCP due to the range buildup with differentiating features that make up the high, mid and low-end of the product range. Low-end type Thor has a different set of features that high-end Thor and therefore a different FCP. Also the volumes for different types influences the average FCP, as higher volumes usually trigger a lower FCP. Sales estimations at PPC could differ from actual sales volumes at milestone PE, therefore influencing the project outcome. However, with total volumes of typical shaver projects ranging from 2 to 5 million for Thor/Mpire/SR3 to 20 million for the Chinese shaver project Wukong, a difference in 0,10 eurocent in FCP translates in a difference of 200k to 2 million euro less profit.
As the Management Team is aware of the difficulty of setting hard targets on the financial metrics, projects get targets set through comparing the predecessor project outcome and setting an individual target for the current project. For instance project Wukong develops a shaver that is comparable with the predecessor project Tiger. The targets for Wukong on financials were 30% less TIC and 25% less CAPEX than Tiger. The individual target setting does show the wish of the Management Team to have more efficient projects regarding financial metrics.
Conclusion: It is hard to conclude whether the overall IPD process is efficient using the TIC, CAPEX and
FCP metrics, as the estimations used to come to these outcomes render these metrics unreliable.
Throughput time of project
Management has set a target throughput time of 86 weeks for IPD projects, depicted in the upper bar in Figure 17, as well as the target time between individual milestones. The projects Mpire and SR3 were not within target time, which is displayed through the red markings in the project throughput bars in Figure 17. Comparing the ideal state of projects and the base project outcomes, the IPD process does not perform conforming target. Furthermore it appears that there are two distinct timeslots that cause delays, being the fuzzy front end (Ulrich & Eppinger, 2008) between milestone PB and PPC, and the pre-production phase between milestones PC/PV and IR.
Conclusion: Based on the throughput time metric, the IPD process is not efficient.
27
3.3.4 IPD & Usefulness:
Usefulness describes the emotional bond between the organizational members and the work of the organization. Employees should have an emotional bond with their co-workers and the organization, as without it an organization can become inefficient or even ineffective (De Leeuw, 1994). In in-depth interviews, there were no apparent signs of abnormal issues regarding the emotional bond between employees involved in the IPD process and the organization or amongst each other. Therefore, this aspect of the triptych of Haselhoff (De Leeuw, 1994) will be excluded in this thesis.
3.3.5 Stakeholder analysis
Pitfalls in determining the right problem and the focus of research are either recognizing too few problem owners or addressing problem owners as collectives (De Leeuw, 1994). De Leeuw (1994) states that a problem owner is an individual person with a sense of dissatisfaction about a situation. This feeling of dissatisfaction has three causes: the perception of the situation of that person, the desired state of the situation by that person and the reality of the situation. Moreover, there could be multiple problem owners, which all have differing perceptions and desired states of the situation. The Consumer Lifestyle Management experiences the performance of IT Shaving as unsatisfactory, as there are targets set for improvement of this performance. The IT Shaving Management Team experiences the output of the IPDs as unsatisfactory, as the MT is responsible for the performance of IT Shaving. Furthermore, the functional department managers of Mechanical Development, Project Management, Product Research Centre and Development Quality are responsible for the execution of projects and the products produced and are not satisfied with the output of the IPD. Therefore, these stakeholders can be regarded as problem owners. There is consensus amongst these stakeholders that the goal of the IPD is to turn out effective products in an efficient way and that the current IPD performance, measured by the previously described metrics, needs improvement.
3.3.6 Goal/perception/reality analysis
28
3.3.7 Conclusion of problem identification
To conclude the first diagnosis phase of this research, the following can be concluded on the problem identification:
- The results of the analysis performed through applying the triptych of Haselhoff underline the functional nature of the problem as the output of the system is not conforming to the preset targets for effectiveness, as well as the efficiency with which the output is achieved can be improved.
- The throughput time metric indicates that the IPD is not efficient - The field call rate metric indicates that the IPD is not effective - Conclusions drawn from other metrics are more ambiguous.
- It has been established that the functional problem is not due to unrealistic goal setting or perception of management.
- There is consensus amongst influential stakeholders on the goals of the IPD and the problem statement.
Therefore, the functional problem can be summarized as follows:
The output of the IPD process is not conforming targets
The research goal of this thesis is:
Improve the output of the IPD in order to conform to the targets.
3.4 Problem analysis
In this paragraph a causal model will be shown with the intent of explaining the causes of the functional problem. The causal model was devised using facts and ideas from the organization and theory to find an explanation for the functional problem (Prins, 2008). To construct the causal model the insights gained from interviews were supplemented with literature to form a pluriform view on the possible causes of the functional problem. The information found was then triangulated within the organization through a data-driven approach.
29
Changes in product during IPD
(TCP)
Quality related product defects (FCR without NFF)
Proposition related product defects
(NFF)
Low customer satisfaction (NPS) E ffi cie n cy E ffe ct iv e n e ss Inefficient Requirements Development Ineffective environment analysis Test methods not matching requirements Focus on CTQs Re-use of requirements not structured Problematic Requirements flowdown Requirements defects Adding requirements after freeze Implementation defects 1 2 3b 3c 4 4a 4b 4c 5 5a 5c 5b Throughput time 6 Technology Innovation Cost (TIC) Capital Expenditure (CAPEX) Factory Cost Price
Overspecifying 3 3a 6a 6b 1a 7. Overall moderator: Cross-functional integration Functional problem: IPD output not conforming
targets 3.4.1 Causal Model II
The causal model II in Figure 18 shows which variables probably cause the defined functional problem. The variables and links displayed in red indicate the scope of this research, as established in paragraph 3.4.3
30
3.4.2 Quick guide to causal model:
Relation Explanation in Main Text
1/1a Inefficient requirements development at the start of the project cause requirements to stay vague which causes inefficiencies as it is unclear to engineers what to develop as well as changes later on in the project. This increases throughput time of the project. 4a Requirements stem from the product’s environment, including load cases brought on by
users, the physical place the product is used, etc. If the analysis of this environment is not done effectively, requirement defects occur in the product.
5 Any forgotten or badly formulated requirements caught during the project cause changes in the product which are filed as TCPs, or Technical Change Proposals.
5a Any forgotten or badly formulated requirements not caught will cause defects in the market (FCR)
5b Any forgotten requirements will cause proposition related product defects (No Failure Found Call Rate) as the product does not fulfill all wishes of the customer
5c Any forgotten or badly formulated requirements will cause low customer satisfaction (Net Promoter Score) as the product does not fulfill all wishes of the customer.
6/6b/6a Changes in the product during the project will cause extra time spent in the pre-production stage, more spenditure of the development budget (TIC), as changes in the design have to be made and more capital expenditure on production facilities (CAPEX), as moulds and tooling needs to be changed.
7 On a higher aggregation level, cross functional integration between R&D, Marketing, Design and Manufacturing stakeholders is key as the processes that lead to the IPD output are dependent on the team work of those stakeholders.
Relation Explanation in Appendix Appendix no
2 Adding requirements after the requirements freeze means changing the design of the product. Changes are documented as TCPs, or Technical Change Proposals.
Appendix B1
3/3b Test methods that do not match requirements cause either overspecification of the product, as the tests are too strict, or (implementation) defects, as the tests are too lenient and defects in the product slip through.
Appendix B2
3a Implementation defects, caused by too lenient test methods, cause defect products in the market. The rate of defects relative to the total production is called Field Call Rate (FCR),
Appendix B2
3c Overspecification of the product, caused by too strict test methods, cause a relative high Factory Cost Price (FCP) per product as the specifications are better than the requirements.
Appendix B2
4 A special focus on the Critical to Quality requirements cause basic requirements to be missed or to be badly defined, causing (requirement) defects in the product,
Appendix B3
4b Translating consumer requirements to technical requirements is a difficult process. Any mistakes in this process create requirements defects in the product.
Appendix B4
4c Unstructured reuse of requirements from previous projects could cause missed requirements therefore causing requirements defects.
