Consideration of downstream functions in New Product

DEGREE PROJECT IN PRODUCTION ENGINEERING AND MANAGEMENT, SECOND CYCLE, 30 CREDITS STOCKHOLM, SWEDEN 2018

Consideration of

downstream functions in

New Product Development

A case study at Company X

CARL PHILIP FREDBORG

ALEXANDER NILSSON

KTH ROYAL INSTITUTE OF TECHNOLOGY SCHOOL OF INDUSTRIAL ENGINEERING AND MANAGEMENT

I

Abstract

In recent years, customers demand for new products has increased in line with a rapid

technological change. This has put pressure on industrial companies regarding New Product

Development (NPD) in order to continuously develop and produce products at or above the

customers’ expectations. Furthermore, products need to be profitable throughout the whole

product lifecycle.

In order to consider the whole product lifecycle in NPD, inputs with information, as well as,

involvement from/of downstream functions are considered as two critical factors to ensure that

profitable products are developed. Information from other functions with a wide range of

perspectives, knowledge and experiences from previous products are vital.

This thesis uses the above mentioned notion while examining a large multinational company,

Company X. Product Development in the Company X Group follows the Gateway process

which was released group-wide in 2009. This process consists of gateways which cannot be

passed if not all requirements are satisfied in each step. This ensures that all areas are covered

and that products are developed in an effective matter.

Interviews, observations and archive analysis are methods utilized to define the current state at

CXDY. The current workways and processes are compared to the outspoken ones by the

company. Also, the workways and processes are compared to the theory of project management,

product development, Design for X methodology and management of knowledge. In the

analysis, gaps are identified and the authors present their solutions to improve the NPD process

at the Company X

The major findings in the proposed solution were a new approach of the Gateway process that;

takes the Internal Customer into consideration, has clear definitions of roles and responsibilities

and has a cross-functional team that represent the Internal Customer in order to encourage

concurrent engineering.

Due to confidentiality reasons some parts of this report are hidden.

Keywords: New product development, Project management, Product Lifecycle, Concurrent

engineering, Design for X, Management of knowledge.

II

III

Sammanfattning

Svensk titel: Beaktning av nedströmsfunktioner i produktutvecklingsprojekt

Under senare år har kundernas efterfrågan på nya produkter ökat i takt med en snabb

teknologisk utveckling. Detta har ställt krav på tillverkande företag att fokusera på

produktutvecklingprojekt för att kontinuerligt leverera produkter som uppnår eller överträffar

kunders förväntningar. Vidare måste produkterna vara lönsamma genom hela produktlivscykeln.

För att kunna beakta hela produktlivscykeln i produktutvecklingsprojekt anses input med

information och involvering från/av nedströmsfunktioner vara två kritiska faktorer för att

säkerställa att lönsamma produkter utvecklas. I detta är informationen från andra funktioner med

olika perspektiv, kunskaper och erfarenheter från tidigare produkter avgörande.

Denna avhandling behandlar ovanstående tankar när ett stort multinationellt företag, Företag X.

Produktutveckling i Företag X-koncernen följer Gateway-processen som släpptes på grupp-nivå

under 2009. Denna process består av Gateways som inte kan godkännas om inte alla krav är

uppfyllda i varje steg. Detta säkerställer att alla områden har behandlats och att produkter

utvecklas effektivt.

Intervjuer, observationer och arkivanalys är metoder som applicerats för att definiera det aktuella

läget vid CXDY. De nuvarande arbetssätten och processerna jämförs med företagets uttalade.

Arbetssätten och processerna jämförs vidare med teorin om projektledning, produktutveckling,

Design för X-metodik och kunskapsförvaltning. I analysen identifieras luckor och författarna

presenterar sina lösningar för att förbättra produktutvecklingsprojekten på CXDY.

De viktigaste resultaten i den föreslagna lösningen var ett nytt tillvägagångssätt av Gateway-

processen som; tar hänsyn till interna kunder, har tydliga definitioner av roller och ansvar och

har ett tvärfunktionellt team som representerar den interna kunden för att främja Concurrent

engineering.

På grund av sekretesskäl har vissa delar av denna rapport gömts.

Nyckelord: Produktutveckling, Projektledning, Produktlivscykel, Concurrent engineering,

Design för X, Kunskapsförvaltning.

IV

V

Acknowledgements

This thesis is the final piece of our Master’s degree in Production Engineering and Management

at The Royal Institute of Technology (KTH) and has been written during the spring of 2018. It is

the result of a close collaboration between the authors, our supervisors at CXDY and KTH.

We would like to seize this opportunity and thank everyone involved in this thesis. First and

foremost, we would like to thank the individuals of the CXDY organization. They have

contributed with their time and inputs which has been crucial. Especially, we would like to

acknowledge our supervisors Anneli and Mikael. Their input and feedback has been vital in the

creation of this thesis.

We would also like to thank our supervisor Hamzah Ssekiunga Ssemakula at the Faculty of

Production Engineering. He has ensured that the thesis contributed academically, was finished

on time and of good quality.

On a more personal note:

I, Alexander, would like to thank my family for the love and support during my time as a student

in general and during my Master Thesis in specific. Especially, for letting us use the apartment in

Alicante for a week’s writing in the sun. Furthermore, I would like to thank my girlfriend Alice

for her understanding throughout my academic years, as well as, her help with the dishes when I

had a plastered arm. Finally, I thank Carl Philip for a pleasant time and great collaboration during

our Master Thesis.

I, Carl Philip, would like to thank my family which has supported me throughout all my

academic years. Especially, I would like to thank my mother. Without her I would never have

completed the five years at KTH. I would also like to thank my girlfriend Amanda. Her patience,

understanding and support has been vital for me. Last but not least, I thank my colleague

Alexander. It has been a pleasure.

We would also like to thank our friends at school, especially the members of “Pingisklubben” for

the support during the last two years.

________________________ ________________________

Alexander Nilsson Carl Philip Fredborg

VI

VII

Abbreviations

AR - Action Request

BOM - Bill of Material

BU – Business Unit

BUM – Business Unit Manager

CAD - Computer Aided Design

CAE - Computer Aided Engineering

CAM - Computer Aided Manufacturing

CE – Concurrent Engineering

CFO – Chief Financial Officer

CM - Change Message

CP - Change Proposal

CPI - Continuous Product Innovation

CRM - Customer Relationship Management

CTO - Chief Technology Officer

CXDY – Company X Division Y

DFA - Design for Assembly

DFD - Design for Disassembly

DFI - Design for Installation

DFLC - Design for Lifecycle

DFM - Design for Manufacturing

DFMa - Design for Maintenance

DFX - Design for X

EPD - Existing Product Development

EqS - Equipment Sales

ERP - Enterprise Resource Planning

FOPS – Field Operations

GW - Gateway

KB - Knowledge Base

KPI - Key Performance Indicator

LCC - Life Cycle Cost

LRU - Line Replacement Unit

VIII

MRS – Market Requirement Specification

NPD – New Product Development

NPI - New Product Innovation

PD - Product Development

PDM – Product Data Management

PS - Pedestrian Solutions

PLM – Product Lifecycle Management

PPI - Pre Product Innovation

PRS – Product Requirement Specification

Q - Quality

R&D – Research and Development

RD - Revolving Door

SC - Supply Chain

SL - Sliding Door

SW - Swing Door

TTM - Time To Market

UBR - Unique Buying Reason

USP - Unique Selling Point

VA/VE - Value Analysis & Value Engineering

VOC - Voice of Customer

VOIC - Voice of Internal Customer

VP - Vice President

IX

Table of Content 1 Introduction ........................................................................................................................................ 1

1.1 Background ................................................................................................................................. 1

1.2 Problem statement ..................................................................................................................... 1

1.3 Purpose ........................................................................................................................................ 2

1.4 Scope and delimitations ............................................................................................................. 2

2 Company presentation ...................................................................................................................... 5

3 Theoretical framework ...................................................................................................................... 7

3.1 Design for X ............................................................................................................................... 7

3.1.1 Design for assembly .......................................................................................................... 7

3.1.2 Design for manufacturing ................................................................................................. 7

3.1.3 Design for disassembly ..................................................................................................... 8

3.1.4 Design for lifecycle ............................................................................................................ 8

3.1.5 Design for maintainability ................................................................................................ 9

3.1.6 Design for Installation..................................................................................................... 10

3.2 Management of knowledge ..................................................................................................... 10

3.2.1 Product data management (PDM) and Product lifecycle management (PLM) ...... 10

3.2.2 The PLM system .............................................................................................................. 11

3.2.3 PLM as a knowledge management system ................................................................... 12

3.2.4 Communication ................................................................................................................ 13

3.3 Organization ............................................................................................................................. 13

3.3.1 Matrix organizational structure ...................................................................................... 13

3.4 Project management ................................................................................................................ 14

3.4.1 Planning and control ....................................................................................................... 15

3.4.2 Roles and responsibilities ................................................................................................ 15

3.5 Product Development ............................................................................................................. 17

3.5.1 Introduction and delimitations ...................................................................................... 17

3.5.2 Technology push and market pull ................................................................................. 18

3.5.3 Market trends .................................................................................................................... 19

X

3.5.4 New Product Development (NPD) .............................................................................. 20

3.5.5 Concurrent engineering ................................................................................................... 22

4 Method .............................................................................................................................................. 25

4.1 The approach ............................................................................................................................ 25

4.2 Data collection .......................................................................................................................... 26

4.2.1 Interviews .......................................................................................................................... 26

4.2.2 Archive analysis ................................................................................................................ 27

4.2.3 Observations ..................................................................................................................... 27

4.3 Qualitative and quantitative analysis ...................................................................................... 28

4.4 Reliability and validity .............................................................................................................. 28

5 Current state ..................................................................................................................................... 31

5.1 Interviews .................................................................................................................................. 31

5.1.1 Questionnaire ................................................................................................................... 31

5.1.2 Results from questionnaire ............................................................................................. 34

5.1.3 Open-ended interviews ................................................................................................... 39

5.1.4 Results from open-ended interviews ............................................................................. 39

5.2 Archive analysis ........................................................................................................................ 39

5.2.1 Gateway process............................................................................................................... 39

5.2.2 Organizational charts ....................................................................................................... 42

6 Analysis .............................................................................................................................................. 45

6.1 Identified problems in the current state ................................................................................ 45

6.2 Analysis of identified problems .............................................................................................. 45

6.2.1 Consideration of other functions in NPD ................................................................... 45

6.2.2 The Gateway process ...................................................................................................... 47

6.2.3 Concurrent engineering ................................................................................................... 52

6.2.4 Roles and responsibilities ................................................................................................ 53

6.2.5 Corporate culture ............................................................................................................. 54

7 Future state ....................................................................................................................................... 57

7.1 The proposed Gateway Process ............................................................................................. 57

XI

7.2 Roles and responsibilities ........................................................................................................ 58

7.2.1 The Internal Customer .................................................................................................... 58

7.2.2 The Reference Group and Function forums ............................................................... 58

7.2.3 The Product Council ....................................................................................................... 59

7.2.4 The Product Manager ...................................................................................................... 59

7.2.5 The Program Manager .................................................................................................... 59

7.2.6 The Product and Program Manager .............................................................................. 59

7.3 Activities .................................................................................................................................... 60

7.3.1 The Gateway meeting ...................................................................................................... 60

7.3.2 Inputs to NPD and Product requirements .................................................................. 61

7.3.3 Activities to implement ................................................................................................... 62

7.4 Concurrent engineering ........................................................................................................... 62

8 Discussion and future recommendations ..................................................................................... 65

8.1 Contribution .............................................................................................................................. 65

8.2 Inputs to the NPD Process .................................................................................................... 66

8.3 Involvement in the NPD Process .......................................................................................... 67

8.4 Corporate culture ..................................................................................................................... 68

9 Table of References ......................................................................................................................... 69

10 Table of figures ................................................................................................................................ 73

11 Table of tables .................................................................................................................................. 75

12 Appendix

12.1 Appendix A

12.2 Appendix B

12.3 Appendix C

12.4 Appendix D

12.5 Appendix E

12.6 Appendix F

12.7 Appendix G

XII

1

1 Introduction

In this chapter a brief background of the thesis is presented followed by the problem statement, purpose, scope and

delimitations.

1.1 Background

Company X is the global leader in door opening solutions. The group was founded in 1994

through the merger of a Swedish company and a Finnish competitor. Since the inception the

company has grown organically but also via acquisitions of door and security companies. As of

2017 the group has become global, employs 47 000 and annual sales exceed 7.9 billion EUR.

The group is divided into five divisions where one of them is Division Y. Company X Division

Y (CXDY) is the division within the Company X group that supply the market with automated

entrance solutions through a direct and an indirect channel. The division develop, produce, sell,

install and maintain door and docking solutions ranging from large hangar doors to swing door

operators for pedestrian purposes. Thus, CXDY are involved in the whole lifecycle of their

products because everything from Product Development to maintaining customers door

operators are business areas where they conduct business.

Product Development in the Company X Group follows the Gateway process which was

released group-wide in 2009. This process consists of gateways which cannot be passed if not all

requirements are satisfied in each step. This ensures that all areas are covered and that products

are developed in an effective matter. Also this tool works as a communication tool for top

management where the current state of a development project can be realized by looking at the

progress in the gateway process.

The wide range of business areas within CXDY requires good collaboration between the

different functions of the company, in reality this is not always the case. From this notion the

opportunity for this thesis arose. The thesis is primarily concerned with the collaboration

between the Product Development function and the field operation functions, as well as the

Sales function, of CXDY. The field operations involve installation and service of customer

operators. The Service function is divided into preventive maintenance, break downs and

upgrades.

1.2 Problem statement

In recent years, customers demand for new products has increased in line with a rapid

technological change (Miao & Chen, 2011). This change has shortened the product lifecycle and

2

the development of new products has evolved into being compulsory for companies in order to

survive on today’s competitive market (Ibid.). In addition, the design of a product is considered

to influence the total cost of a product with between 70% and 85% (Dowlatshahi, 1992).

New Product Development (NPD) is described as the process of transforming business

opportunities into tangible products (Trott, 2005). When a new product is developed it is

important to consider the whole product lifecycle and calculate with costs and revenues

throughout the entire product lifecycle, i.e. the lifecycle cost (LCC).

In order to consider the whole product lifecycle in NPD, inputs with information, as well as,

involvement from/of other functions are considered as two critical factors. Trott (2005)

highlights the importance of involving other functions in NPD in order to collect valuable

information from people with a wide range of perspectives, knowledge and experiences from

previous products.

Nevertheless, collaboration between NPD and other functions are important in order to

maximize profit throughout the whole product lifecycle. In order to succeed with this every

function shall have the ability to contribute with inputs to the NPD, as well as, being involved in

the NPD process. If this not is done sufficiently, there is a gap in the collaboration between

NPD and other functions that will constrain the ability to develop products that are competitive

and profitable.

1.3 Purpose

The purpose of this thesis is to propose a solution for how to coordinate information flow to

NPD and how to increase the level of involvement from other functions into the NPD process.

1.4 Scope and delimitations

This thesis will primarily focus on the direct channel because only in the direct channel CXDY is

present through the whole product lifecycle, from product development to maintaining

customers door solutions. Since CXDY is a global company and the business is scattered over

the globe a selection of a business area was necessary in order to minimize travel and maximize

meetings with key persons and stakeholders of the organization. The decision was taken to

examine Pedestrian Solutions (PS) because this business area had most of the key functions

located in one place. However, the outcomes of this thesis are expected to be valuable in the

other business areas as well where all are expected to strive for business excellence and work in

more or less the same ways.

3

In order to further limit the scope of this thesis a pre-study was conducted where stakeholders

within PS were interviewed. In this study it was recognized that the involvement of Sales,

Installation and Service functions in the Product Development process was important to ensure

profits throughout the whole product lifecycle. Therefore, focus were put on the interaction

between these functions.

This thesis is delineated to examine functions which generates a positive cash flow namely Sales,

Installation and Service. Efforts were made to increase the level of involvement by proposing

changes of workways and processes at CXDY. This thesis also investigated different ways of

efficiently collecting inputs from the functions which interacts with the product throughout the

whole lifecycle.

4

5

2 Company presentation

Due to confidentiality reasons, the following chapter about Company X cannot be published.

6

7

3 Theoretical framework

In this chapter, the theoretical framework of concepts, definitions and theory that is considered as relevant to the

thesis is presented. Those are design for x, management of knowledge, organization, project management and

Product Development.

3.1 Design for X

When products are developed different approaches might be undertaken to satisfy specific

demands from Internal and External Customers. Design for X (DFX) methods are approaches

that targets different areas of a product regarding functions. DFX research emphasizes that

design goals and their constraints have to be addressed at an early stage. The application of these

methods requires that designers and engineers work in cross-functional teams which occasionally

creates friction (Kuo, Huang, & Zhang, 2001). This implies that more issues regarding

integration must be addressed during the process.

Below a brief introduction to different DFX-approaches are presented.

3.1.1 Design for assembly

Design for assembly (DFA) is based on the notion that the lowest assembly cost can be achieved

by designing products and parts in such a way that it can be economically assembled by the most

convenient assembly system. Boothroyd and Dewhust presented a handbook for this theory in

1986 and are considered to be pioneers in this field of designing of assembly (Boothroyd &

Dewhurst, 1986). In this handbook the authors where parts were rated in the assembly based on

the ease of handling and insertion. All techniques presented by the authors are keys of

minimizing the cost of assembly but still satisfying the other constraints of the products design

(Ibid.). There are primarily two factors that influence the assembly cost: the total number of

parts in the assembly and the ease of handling, insertion and fastening of the different parts.

3.1.2 Design for manufacturing

When new parts are designed a selection of material and manufacturing process is of importance.

The selection of process and material are a matching approach where the functionality of the

part has to be satisfied. At the same time it is important to design parts in a way where cost is

minimized. The approach of keeping the manufacturability in mind when designing is called

design for manufacturing (DFM). As mentioned above the material and process is important to

keep costs as low as possible. But modular design, multi-use part development, standard

components, separate fasteners and assembly direction minimization are also key factors for

8

minimizing the total cost of manufacturing a part or product. These factors were presented by

(Kirkland, 1988) as being important for minimizing cost in the manufacturing.

3.1.3 Design for disassembly

Since the inception of “Design for X” concepts focus has been put on minimizing costs of

producing parts. However, more recent recycling of products has become increasingly important.

In order to successfully increase the recyclability of the product efforts are put into designing

parts that can be disassembled in an efficient manner as well. Disassembly is defined by Brennan,

Gupta and Taleb (1994) as “the process of systematic removal of desirable constitute parts from

an assembly while ensuring that there is no impairment of the parts due to the process”.

It was proven in a study by Harjula et al. (1996) that the tools in a DFA-analysis will be beneficial

for the disassembly of a product. The authors recognized that these tools would increase both

the assembly and the disassembly. In addition more efforts could be deployed in the area for

Design for Disassembly (DFD) to ensure that the product could be disassembled effectively.

3.1.4 Design for lifecycle

Design for Lifecycle (DFLC) involves the whole lifecycle of a product. The lifecycle areas of a

product involves early product concept, product/market research, design phases, certification,

manufacturing processes, installation/assembly, customer service, maintainability and

supportability (Kuo, Huang, & Zhang, 2001). All these areas must be addressed in all the phases

of a product lifecycle. The six phases of a product lifecycle were distinguished by Boothroyd and

Alting (1992) as being:

1. Need recognition

2. Design development

3. Production

4. Distribution

5. Use

6. Disposal

The lifecycle costs of a product can be divided into two parts for stakeholders: costs of design

and production and costs of operation and/or service (Kuo, Huang, & Zhang, 2001). These

costs can be divided between three stakeholders: Company, User and Society (Jovane, o.a.,

1993).

9

3.1.5 Design for maintainability

Maintainability, is defined by Kapoor and Lamberson (1977) as “the probability that a failed

system can be repaired in a specific interval of downtime”. The most important aspect of Design

for Maintainability (DFMA) is to secure that a product can be maintained throughout its whole

lifecycle at a reasonable expense without difficulty (Kuo, Huang, & Zhang, 2001). Maintainability

requirements can take the form of design guidelines in order to secure ease of maintaining the

product. These guidelines define requirements such as: accessibility, detection and isolation of

failure, weight limitations of replaceable parts, dimensional limits in order to secure ease of

transport of replacement parts and design requirements to secure that replaceable parts are

compatible with robot assisted removal and replacement (Ibid.).

The following list provides a designer with general DFMA guidelines (Ibid.):

General design features

o The design shall hinder the possibility of damaging the equipment during

maintenance and service

o Minimize the use of special solutions which require special tools

o Part reference number shall be located next to each part legibly

o Guidance pins shall be used for correct alignment of modules

o Sharp edges or protrusions that could harm technicians shall be avoided

o Handles shall be provided on removable parts that weigh an excess of 5 kg

o Keying shall be used to ensure that reassembly are done in the right order

Mounting and location of units

o Provide a design solution which makes replacement of line replacement units

(LRU) without removal of undamaged parts

o Provide a design solution which makes removal of LRUs without interrupting

critical functions

o Heavy unit shall be mounted as close to the floor as possible

o Provide a design solution that allows ease of replacing LRUs. Units shall be

mounted on chassis or structure rather than mounting on other parts

Test and calibration

o Adjustments shall be designed in an uniform way for example clockwise, right or

up for increase

o Test points on circuit boards shall be designed so in-circuit testing is possible

o Calibration and adjustment levers shall be designed with stops to prevent damage

10

Cables, leads, wiring and connectors

o Clearing around connectors shall be provided to ensure accessibility and viewing

o Cables shall be routed to facilitate tracing, removal and replacement

o Cable shall be labeled throughout their length to ensure identification

o Service loops shall be provided to facilitate maintenance and service

3.1.6 Design for Installation

Design for Installation (DFI) is the method where focus directed towards the ease of installing

the product. The method is similar to the other Design for X methods but here the designers

and engineers collaborate to invent products that can be installed quicker, simpler and more

efficient without any specialized expertise (Maltzman, o.a., 2005).

3.2 Management of knowledge

It is becoming increasingly more important to manage knowledge in order to stay competitive in

the market. In order to fully understand what knowledge is three different terms that are used

interchangeably to misleadingly describe the same thing are analyzed. Data, information and

knowledge are the three terms (Cambridge Dictionary, 2018):

Data: Information, especially facts or numbers, collected to be examined and considered

and used to help decision-making

Information: Facts about a situation, person, event, etc.

Knowledge: Understanding of or information about a subject that you get by experience

or study, either known by one person or by people generally

When analyzing these definitions a clear hierarchy can be realized. Knowledge is understood

information which relays on data. So for corporations in the information age the management of

knowledge is of importance. Data and information is easier to gather and store than knowledge.

Research has shown that only 4% of organizational knowledge is stored and available in a

structured way. The rest is unstructured or stored in people's minds (Rasmus, 2002).

3.2.1 Product data management (PDM) and Product lifecycle

management (PLM)

In the later part of the 1980s Product Data Management (PDM) appeared which controls and

manage the data created around the product. The sole purpose of these early PDM systems was

to provide users with required data insure integrity of the data by continuous control and

updates (Ameri & Dutta, 2005).

11

The implementation of PDM systems were supplemented over time with functionalities like

document management, change management, workflow management and project management

that promised enterprises a streamlined Product Development process and concurrent

engineering. The early PDM systems were effective in the engineering domain but failed to

handle non-engineering areas like Supply Chain Management, Sales and marketing. Also these

systems failed to encompass external agents such as customers and suppliers. Two major reasons

for the early PDM systems failure was that an engineering or technical background was needed

to handle the system and the system primarily handled engineering data like drawings and Bill Of

Material (BOM) lists. These shortcomings can be rooted to the development of PDM systems

where they were considered to be support systems to Computer aided design (CAD), Computer

aided manufacturing (CAM) and Computer aided engineering (CAE) systems. (Ibid.)

During the same era as PDM systems were introduced the first solutions for Enterprise

Resource Planning (ERP), Supply Chain Management (SCM) and Customer Relationship

Management (CRM) systems were simultaneously developed. These systems were introduced to

further streamlining the business practices of enterprises. Each of these systems were

independently focusing on different areas of the products lifecycle and heavily depended on

information about the product. However, problems arose in supportability from the PDM

system, unlike the support PDM provided for CAM/CAD/CAE, due to the focus on

engineering data. (Ibid.)

The Product Lifecycle Management (PLM) systems appeared later in the 1990’s with the task of

providing a shared platform to support the enterprise systems mentioned previously. The data

handled by the PLM system should include much more than just engineering data like design and

manufacturing. Example of such information is marketing, sale, after sale service. So the PLM

should support the whole lifecycle of a product.

The objective of PLM is minimize product-related cost, maximizing product revenue, maximize

value of product portfolio and maximize value of current and future products for both end-users

and the enterprise (Stark, 2017).

3.2.2 The PLM system

The PLM system is interacting with all business processes of an enterprise and stores all

necessary knowledge regarding the products. The system is built on the foundation of a

knowledge base (KB). This KB doesn’t necessarily consist of a connected database, instead it

could be an interconnected network of knowledge that is spread out through different systems.

The PLM system should also be present throughout the whole lifecycle of a product. The agents

12

of the lifecycle communicate with the PLM system in two ways: either they add new knowledge

to the KB, this is called telling (TELL), or the agent look for answers for their questions in the

system by asking (ASK) (Ameri & Dutta, 2005). A rough overview is shown in Figure 4 PLM

system overview.

Figure 1 Adopted from (Ameri & Dutta, 2005): PLM system overview

3.2.3 PLM as a knowledge management system

An effectively implemented PLM system can aid all business processes of an enterprise, from

R&D to after sales service. Organizations with an extensive knowledge management system

becomes more effective where knowledge is stored and managed. Knowledge becomes easy to

access and decisions are reinforced by using the updated knowledge of the organization (Ameri

& Dutta, 2005).

In Figure 5 Learning capacity the relationship of acquired knowledge over time is shown. The

dotted line indicates the presence of a knowledge management system such as PLM.

Figure 2 Adopted from (Ameri & Dutta, 2005): Learning capacity

13

The improved learning capacity also facilitates the increase of cash flows, this is shown in Figure

6 Cash flow. The improved cash flows is a reaction on more knowledge reinforced decision in the

enterprise.

Figure 3 Adopted from (Ameri & Dutta, 2005): Cash flow

A well-established knowledge management system will contribute to organizations of achieving

competitive advantages of today in terms of innovation, customer intimacy and operational

excellence. These are regarded as the internal forces of an enterprise. The external forces of the

enterprise are considered to be globalization, product complexity, shrinkage in product lifecycle,

push into supply chain and environmental issues. All these internal and external forces can be

helped with a PLM or equal knowledge management system (Ibid.).

3.2.4 Communication

Communication is about spreading information and sharing knowledge with others, a strategy

for communication is of importance in large organizations with many stakeholders. In the

strategy, the best-suited communication channels, as well as, infrastructure for the information

flow needs to be determined in order to “ensure that the right target group gets the right

information at the right time and in the appropriate way” (Tonnquist, 2012, s. 203). In otherwise,

the risk for making mistakes that may upset stakeholders whom feel overlooked increases.

(Tonnquist, 2012)

3.3 Organization

3.3.1 Matrix organizational structure

A matrix organizational structure is a way to combine a functional structure and a market-based

structure in order to achieve advantages from both of them. Advantages from a functional

14

structure by allocating similar tasks, such as purchasing, production and service to specific

departments; and from a market-based structure by allocating responsibilities for different

products, projects or customer segments to specific divisions. (Jacobsen, Thorsvik, & Sandin,

2014)

A matrix organizational structure is also referred to as a two-dimensional structure. Jacobsen et

al. (2014) points on the fact that in a two-dimensional structure, every employee in a matrix

organization has at least two chiefs, which is illustrated by Ford and Randolph (1992) in Figure 7

Matrix organizational structure.

Figure 4 Adopted from (Ford & Randolph, 1992): Matrix organizational structure

3.4 Project management

Due to the fact that new Product Development mostly is performed through projects, the basic

theory and the vocabulary of project management will be described. The definition of the project

as a work form is a unique assignment with limited resources that should be performed in a

predetermined time (Hallin & Karrbom Gustavsson, 2012).

Models such as waterfall, stage-phase or stage-gate are in this thesis referred to as traditional

project management. Main characteristics of traditional project management are methods for

planning and control, sequential project lifecycle stages and a predictable process (Hass, 2007).

Planning and control is important when resources are utilized in order to finish the project on

time and budget. A predictable vision and process is considered as a requirement in traditional

15

project management because in otherwise it would not be possible to set up activities within the

project stages.

The traditional project has a project goal that is specific and well-defined (Tonnquist, 2012). In

some cases where the vision of the project is not obvious, it may not be possible to set specific

and well-defined goals, then it is appropriate to apply an agile project management method

instead (Hallin & Karrbom Gustavsson, 2012). In agile methods, the planning model for the

project execution need to be more flexible and the stages that the project needs to go through is

not determined in advance (Ibid.).

3.4.1 Planning and control

Once one stage in the project is completed, the aim is that it never should be revisited (Hass,

2007). In purpose to control the outcome of each stage, tools called tollgates are utilized. A

tollgate occurs after each gate in a meeting where achieved project results are evaluated and the

future of the project is determined. The outcome from a tollgate can either be 1) continue, 2) go

back, or 3) close. (Tonnquist, 2012)

Another tool is the milestone, which has the purpose to control the project during the execution

phase. Milestones are either activities that needs to be performed or deliverables that needs to be

reached in order to fulfill the project goal. (Tonnquist, 2012)

3.4.2 Roles and responsibilities

In traditional project management, it is important to structure the project organization by

assigning project roles and determine its responsibilities. Depending on the responsibilities in the

project, Hallin and Karrbom Gustatvsson (2012) describes that roles can be categorized into

following four functions, which are illustrated in Figure 8 Functions and roles in a project:

Management function

o Project Manager

Control function

o Steering Committee

o Project Owner

o Client/user/recipient

o Resource Owner/sponsor

Executive function

o Project Group

o Project Team Members

16

o Project Controller

Advisory function

o Reference Group

Figure 5 Adopted from (Hallin & Karrbom Gustavsson, 2012): Functions and roles in a project

The two most important roles in a project is claimed to be the Project Owner and Project

Manager. The Project Owner has the overall responsibility for the outcome of the project and, in

addition, he or she is responsible for allocating resources and that the assignment, or project

goal, is well-defined and specific (Tonnquist, 2012).

The responsibility for the execution of the project, on the other hand, is delegated from the

Project Owner to the Project Manager. The execution of the project consists of delivering a

result that fulfills the project goal to the Project Owner by managing the executive function

(Tonnquist, 2012). In some industries, the Project Manager role can be divided into two roles,

Project Manager and project leader, where the Project Manager is responsible for the financial

part and the project leader for the managerial part (Ibid.).

Furthermore, resource owners are usually Line Managers within the control function whom are

separated from the project group but, nevertheless, are responsible to provide the project with

required competence. The cooperation between Project Managers and resource owners is

important since the project group members often work in a matrix structure and have

responsibilities in the organization under a Line Manager, as well as, in the project under a

Project Manager (Tonnquist, 2012). Another role within the control function, mainly used in

larger projects, is the Steering Committee role that is independent from other project roles and

often used to report the status and progress of the project. Primarily, the committee is involved

17

in the most important tollgate decisions regarding whether the project should continue or be

closed. (Ibid.)

The executive function consists of people who perform the actual work in a project. Within the

executive function, the work is mainly performed by the project team members who are

responsible for planning, organizing and executing activities based on instructions given by the

Project Manager. In addition, project members need to make sure that methods and routines are

followed and quality requirements are fulfilled. (Hallin & Karrbom Gustavsson, 2012)

Within the advisory function, there may be a reference group which consists of people who are

specialists, either in what the project shall deliver or in the processes against achieving that goal.

The reference group are responsible for giving advices on how the project can meet the

requirements and has a supporting role to the Project Manager, the Steering Committee and the

Project Owner. It is often the Project Managers’ initiative to involve and ask a reference group

for advice in the project but when and how this is done depends on the circumstances. (Ibid.)

A role that is not described in Figure 8 Functions and roles in a project is the Program Manager role.

A Program Manager is sometimes used in larger organizations where many projects are

performed simultaneously; the responsibility in his or her role is to coordinate resources between

line and Project Managers (Hallin & Karrbom Gustavsson, 2012).

3.5 Product Development

3.5.1 Introduction and delimitations

In recent years, Product Development has evolved into being viewed as one of the most

important functions within a manufacturing company. The main reason for this is because the

design of a product is considered to influence the total cost of a product with between 70% and

85% (Dowlatshahi, 1992).

Knowledge and information from other functions in the company plays a key role in Product

Development as a valuable input to the process. This is illustrated in Figure 9 Product Development

and the design environment, where the wide range of functions are presented horizontally and the

knowledge input to the Product Development vertically (Trott, 2005). Depending on which type

18

of industry, input from one function may be more important than from another but the

important thing is to consider them all in the Product Development process.

Figure 6 Adopted from (Trott, 2005): Product Development and the design environment

By looking into the Product Development process, innovation is a broad concept of which

fundamental knowledge will be required in order to follow this thesis. While discussing

innovation, it is important to understand that innovation not is one single event but instead a

process of several activities that includes several functions (Ibid.). According to this, following

definition of innovation will be applied in this thesis:

“Innovation is the management of all the activities involved in the process of idea generation, technology

development, manufacturing and marketing of a new (or improved) product or manufacturing process or

equipment” (Trott, 2005, s. 23)

Among several types of innovations, this thesis will only examine product innovation that shortly

could be described as the development of a new or improved product (Ibid.). Furthermore, it is

common to divide product innovation into New Product Development (NPD) and Existing

Product Development (EPD). Of these two, NPD is considered to be most important in this

thesis and is therefore further described in chapter 3.5.4 New Product Development (NPD).

3.5.2 Technology push and market pull

Traditionally, there were two distinctive models within product innovation; the technology-

driven model and the customer need-driven model (Trott, 2005).

What differ the models from each other is what triggers the development of a new or improved

product. In the technology-driven model, also referred to as technology push, scientists triggers

19

the Product Development process by making unexpected discoveries in their research. In the

customer need-driven model, also referred to as market pull, marketing triggers the Product

Development process by identifying market needs through interaction with customers. (Ibid.)

The interactive model of innovation, illustrated in Figure 10 The interactive model of innovation, is

developed by the idea of connecting the technology-push model with the customer need-driven

model (Rothwell & Zegveld, 1985). Characteristics of the interactive model of innovation are

that it has no specific trigger point, includes both technology push and market pull, and allows

feedback through linkages with science base and marketplace (Trott, 2005). Furthermore, Trott

(Ibid.) consider that inputs from organization capabilities, needs of the market, and the science

and technology base are required in the development of new products.

Figure 7 Adopted from (Rothwell & Zegveld, 1985): The interactive model of innovation

3.5.3 Market trends

Miao et al. (2011) describes the development of new products as compulsory for companies to

survive on today’s competitive market. This is because customer’s demand for new products has

increased in line with a rapid technological change and, as a result of this, the product lifecycle is

shortened (Miao & Chen, 2011).

A shortened product lifecycle is also mentioned by Olhager (2000) when he claims that this in

recent years have set requirements on shorter Product Development lead time i.e. time to

market. To adapt to these new circumstances, Product Development went from being a

sequential process to an integrated process where the different activities were overlapping each

other in purpose to minimize time to market. An effect of an integrated process is that several

functions are involved in the process at the same time, this is illustrated in Figure 11 Integrated

Product Development process below. (Olhager, 2000)

20

Figure 8 Adopted from (Olhager, 2000): Integrated Product Development process

3.5.4 New Product Development (NPD)

As mentioned above, NPD is considered to be the most important area within product

innovation in this thesis. Trott (2005) describes NPD as the process of transforming business

opportunities into tangible products and points out that several stakeholders (e.g. Marketing and

Manufacturing), with different perspectives, are involved in a NPD process. This wide range of

different perspectives regarding what is most important in the NPD process are frequently

considered as a weakness when it instead should be viewed as a strength; this is because it

consists of valuable information from stakeholders with different experiences of previous

products (Ibid.).

Hsuan et al. (2015) refer to “The six phases of NPD process”, developed by Ulrich and

Eppinger (2015), as the most comprehensive and used model to describe the NPD process. This

model follows the definition by Olhager (2000), of an integrated Product Development process

but describes the steps on a more detailed level in a way that will be valuable in this thesis in

purpose to involve every function in the Product Development process. The most important

theory in each phase are presented in Table 2 The six phases of NPD process.

Table 1 Adopted from (Eppinger & Ulrich, 2015): The six phases of NPD process

Phase 0 - Planning:

Design o Evaluate new technologies o Analyze product platform and

architectural aspects

Marketing o Define market opportunity and

market segments

Manufacturing o Develop a supply chain strategy and

identify manufacturing constraints

Phase 1 - Concept Development

Design o Analyze feasibility of product

concepts o Development of industrial design

concepts o Construct and test demo prototypes

Marketing o Collect information regarding

customer needs o Identify lead and analyze lead users

21

Research department o Propose new technologies

Finance o Set planning goals

Top management o Determine resources to the project

o Consider competitive products on the market

Manufacturing o Estimate the cost to manufacture

the product o Evaluate manufacturing feasibility

Finance o Perform economic analysis

Legal o Analyze possible patent issues

Phase 2 - System Level Design

Design o Create alternative product

architectures o Characterize subsystems and

interfaces o Refine industrial design

Marketing o Create a plan for product options

and product family o Determine target sales price point

Manufacturing o Sourcing suppliers for key

components o Make -or buy analysis o Determine final assembly process o Determine cost targets

Finance o Facilitate make -or buy analysis

Service o Identify service issues

Phase 3 - Detailed Design

Design o Part geometry, materials and

tolerances o Complete documentation of

industrial design control

Marketing o Create marketing plan

Manufacturing o Define production processes and

design tooling o Set up quality control processes o Prepare procurement of tooling

Phase 4 - Testing and Refinement

Design o Testing of reliability, life and

performance o Obtain regulatory approvals and

implement design changes

Marketing o Develop promotion, launch

materials and facilitate field testing

Manufacturing o Facilitate supplier ramp-up o Refine fabrication, assembly

processes and quality control o Train workforce

Sales o Create sales plan

Phase 5 - Production Ramp-up

Design o Evaluate early production output

Marketing o Assign early production to key

customers

Manufacturing o Start operation of the whole

production system

The model is, furthermore, illustrated in Figure 12 The six phases of NPD process below:

22

Figure 9 Adopted from (Eppinger & Ulrich, 2015): The six phases of NPD process

3.5.5 Concurrent engineering

As mentioned in 3.5.3 Market trends, the NPD process has gone from a sequential process to an

integrated process where several functions are involved at the same time and activities are

overlapping each other (Olhager, 2000). This change is in contradiction with the financial

functions view on the NPD process which still has a sequential approach. The NPD process, in

a financial perspective, is illustrated in Figure 13 Cash flow throughout a product lifecycle that shows the

cumulative cash flow effect throughout the entire product lifecycle (Trott, 2005). From Product

Development activities to product launch which generates negative cash flow, to Sales and other

functions which generates a positive cash flow (Ibid.).

Figure 10 Adopted from (Trott, 2005): Cash flow throughout a product lifecycle

23

Functions involved in NPD consider the financial perspective, with a sequential approach, to be

a simplification of the reality and therefore a suggestion from research is to view the process as a

simultaneous or concurrent process with cross-functional interaction (Ibid.). Before

simultaneous or concurrent engineering is described, two different NPD models need to be

distinguished; the departmental-stage model and the activity-stage model.

The departmental-stage model is a linear innovation model where the tasks within the project is

divided and assigned to different departments. A risk with departmental-stage model is the

“over-the-wall” phenomenon where departments will accomplish their tasks and then throw the

project over the wall to the next department, this phenomenon is considered to constrain NPD,

generate rework and create disputes between departments (Ibid.). For example, engineering

department develops prototypes based on technical ideas given from R&D and then throw the

project to manufacturing who will investigate in how to manufacture the product.

The activity-stage model, on the other hand, has the foundation of activities in the project

instead of departments whom will perform them. With an approach that is focusing on activities

and promotes iteration of activities by using feedback loops, this model is considered to be

closer to the reality of NPD but still some critique for the “over-the-wall” phenomenon have

been received (Ibid.). Nevertheless, a cross-functional approach is important when activities are

performed simultaneously within NPD (Crawford, 1997). In Figure 14 An activity-stage model

below, an activity-stage model with activities performed at the same time that vary in intensity

throughout the NPD process is illustrated (Ibid.).

Figure 11 Adopted from (Crawford, 1997): An activity-stage model

Concurrent engineering or simultaneous engineering was applied by several industrial companies

in the late 1980’s in purpose to solve the problems that had been identified through the use of

24

departmental-stage and activity-stage models. The idea of concurrent engineering was presented

by Winner et al. (1988) as a systematic method of designing a product concurrently as

downstream production and support processes. The key to change focus from individual stages

to the entire project is claimed to be the involvement of all functions in the beginning of the

project (Trott, 2005). Two common definitions of the concurrent engineering approach are the

following:

1) “The consideration of all downstream activities which are likely to affect the product's lifecycle

at the product’s design stage” (Pop-Iliev & Nokleby, 2011)

2) “Concurrent Engineering is a systematic approach to the integrated, concurrent design of

products and their related processes, including manufacturing and support. This approach is

intended to cause the developers, from the outset, to consider all elements of the product lifecycle

from concept through disposal, including quality, cost, schedule, and user requirements.”

(Carter & Baker, 1992)

During the development of new products it is of outmost importance to understand the concept

of increasing cost of design changes and decreasing flexibility in design over time (Bowersox,

Closs, & Cooper, 2002). Changes to design are getting increasingly harder the further down the

timeline the project moves. Therefore, concepts and design ideas must be evaluated in earlier

stages of the process, by all involved functions, in order for the project to deliver product that

satisfies a majority of the demands stated by different stakeholder. This concept is illustrated in

Figure 15 Flexibility and cost of changes below.

Figure 12 Adopted from (Bowersox, Closs, & Cooper, 2002): Flexibility and cost of changes

25

4 Method

In this chapter the methodology for the research of this thesis is presented. This methodology provides a foundation

from which the thesis refers to in the analysis in order to answer to the purpose.

4.1 The approach

The methodology can be either fixed or flexible. A fixed methodology implies that the study is

defined before the start. A flexible study is continuously changing throughout the process when

new circumstances appear. (Höst, Regnell, & Runesson, 2006)

The method of this study were of a flexible nature. The flexible approach was chosen due to the

nature of the problem statement. The problem was broad, included many functions, hierarchy

levels and the solution was not obvious. Therefore a flexible approach was needed which could

adapt continuously throughout the project in order to the cope with the new knowledge gained

during the process.

Furthermore, there are four approaches of investigations that all have different ambition levels

and that answers different kinds of questions (Höst, Regnell, & Runesson, 2006). These

approaches are:

1. Explorative

2. Descriptive

3. Explaining

4. Diagnostic and evaluating

The first, explorative, is an approach which gives the investigator an understanding of the

problem and issues connected (Ibid.). This approach was used in the beginning of this thesis in

order to scope and define the problem. By conducting interviews with relevant people of

different functions, observing and analyzing archives a more detailed problem description was

reached. The interviewees for the initial stage were chosen based on relevant function in regards

to the initial problem statement. This method is called quota sampling (Acharya, Prakash,

Saxena, & Nigam, 2013).

The second, descriptive, approach which tries to describe the specific process or situation (Höst,

Regnell, & Runesson, 2006). This approach was used during this theses in order to understand

the outspoken processes and activities at CXDY by further interviews, observations during

meetings and observations and analyzation of archives.

26

The third approach, explaining, tries to answer the question why (Ibid.). This approach was used

in this thesis as well. The reasons behind the problem were also investigated by conducting

interviews and by analyzing processes.

The last approach, diagnostic and evaluating, aims to identify causes of the given situation and

measure effects of an action (Ibid.). In this thesis focus lied on suggestions for a better future

state, this is why this approach was of importance to provide the management with sufficient

knowledge in order to take the right strategic decision.

4.2 Data collection

This thesis primarily used interviews and observations as data collection method. The interviews

were set up in two intervals where data was collected in both a quantified and a qualitative

manner. The interviews were supposed to collect data on how the organization perceive their

situation and how they work. The method was then an analysis of archives. This analysis

investigated the communicated processes and identified gaps between perceived work tasks and

what is stated in documented processes. In the analysis of the current state, the authors also

observed the people and workways. This approach was the triangular approach in which the gaps

were confirmed. In Figure 16 The triangular approach the data collection method used in this thesis

is presented in order to get a holistic understanding of the processes and problems associated

with it. (Höst, Regnell, & Runesson, 2006).

Figure 13 Adopted from (Höst, Regnell, & Runesson, 2006): The triangular approach

4.2.1 Interviews

According to Höst et al. (2006), there are primarily three different types of interviews:

1. Structured

2. Semi-structured

3. Open-ended

27

The structured interview is based on a set of questions that were determined before the start of

the session. These questions are followed meticulously throughout the process and the

interviewee is not allowed to deviate from them. This form of interviews can be seen as a survey.

Semi-structured interviews are more open and the pre-determined questions are used as support.

The questions are not as strict as in structured interviews and can be altered and the order might

be changed in order to keep the process flowing. Open-ended, or unstructured, interviews are

more open and leaves the direction of the interview unhindered. It is up to the interviewer to

make sure that the interview remains on topic. (Höst, Regnell, & Runesson, 2006)

This thesis utilized both structured and open-ended interviews. The structured method were

used in a questionnaire that was sent out to different functions and stakeholders. The open-

ended interviews were used to further extract data from different functions and stakeholders.

These interviews focused on how the stakeholders are involved in the Product Development

process and the interviewees were given the chance to express their thoughts for a potential

future state. Extensive notes were taken during these interviews and the interviewers asked

questions that regarded current workways and their specific tasks in the Product Development

process.

4.2.2 Archive analysis

In an archive analysis previous documentation regarding processes, projects and workways are

studied and analyzed. These documents are connected to the topic but are not generated by the

thesis itself.

In this thesis process flow charts, organizational charts and roles and responsibilities were

primarily studied. These documents covering the processes were studied and compared to the

data collected via interviews. In addition, this information was compared to the observations.

This information supported the analysis of the current state.

4.2.3 Observations

Observations is the action or process of observing something or someone carefully or in order

to gain knowledge. According to Höst et al. (2006), there are two different kind of observations:

1. Participatory

2. Complete

In participatory observations the observer participates in the studied phenomenon. The observer

will have a role and will observe while engaging. The complete observations are more restricted

where the observer only observes. No participation takes place (Höst, Regnell, & Runesson,

28

2006). There are benefits and negatives with both methods. In the participatory approach there is

a chance of becoming bias but trust can be gained from other participants. In the complete

approach the observer can become distant and might lack a full understanding after the

observation.

In this thesis the later approach, complete, was utilized. This was in order to fully observe the

processes and workways as is. These observations were used in order to triangulate the data that

was collected during the interviews and archive analysis.

4.3 Qualitative and quantitative analysis

After the data collection phase the findings needed to be analyzed. Blomkvist and Hallin (2015)

states primarily two different categories for this; qualitative and quantitative. These approaches

are connected to the types of data that are being analyzed. Below in Table 3 Qualitative and

quantitative the differences are presented:

Table 2 Adopted from (Blomkvist & Hallin, 2015): Qualitative and quantitative

Qualitative Quantitative

Words Numbers

Vicinity Distance

Induction Deduction

Contextual understanding Generalizations

Soft, rich data Hard, reliable data

This thesis handled the data collected in the presented manner. A majority of the data were

qualitative due to the interview format of the data collection.

4.4 Reliability and validity

According to Höst et al. (2006) , there are three categories that identifies a valid study:

1. Reliability

2. Validity

3. Representativeness

These categories are concerned with different aspects of the study. Reliability ensures that the

conclusions are well argued for, validity is explaining if the right phenomena is studied and

representativeness that generalizations of results are done properly (Ibid.).

29

Reliability is primarily connected to the data collection and analysis. In order to achieve a high

reliability the study must present how it has been conducted. This is done in order for the reader

to understand and enable an assessment. Letting an external party examine the data collection

and analysis is a good way of finding flaws in the study (Ibid.). This thesis used the supervisors

from CXDY and KTH as externals.

Validity is ensured in this thesis by using a triangular approach in the data collection phase. This

approach will provide a foundation and make sure that what is said to be examined is actually

examined.

Since this thesis only concerned one company within a large group this study is not

representative and cannot be generalized. However, similarities of conditions at CXDY could be

found elsewhere and the same phenomenon can occur. To increase representativeness this thesis

put a lot of effort into studying the company and the prerequisites associated. This will help the

reader to understand if other companies are in a similar situation and if results from this thesis

can be applied elsewhere to a certain extent.

30

31

5 Current state

In order to define the current state of the Product Development process and its level of involvement of other

functions; interviews, observations and archive analysis have been conducted. In this chapter, the structure of the

interviews and results from the data collection is presented.

5.1 Interviews

The interviews were conducted in two intervals where questionnaires, as well as, open-ended

interviews have been utilized. Below these are presented separately.

5.1.1 Questionnaire

Two different questionnaires have been conducted; one for Product Development and one for

Sales, Installation and Service. Both of them included quantitative, as well as, qualitative

questions and have been sent out to a wide range of people with different roles in each function.

The selection process of whom to send the questionnaire was determined in collaboration with

supervisors to ensure that people with good experience and knowledge were reached, as well as,

collecting different perspectives of the business. The questionnaire design is described in the text

below and quantitative, as well as, qualitative results are presented in 5.1.2 Results from

questionnaire.

Product Development

In question 1, the respondent rated Sales representative’s level of involvement in NPD on a scale

from 0 to 6. If the answer was 1 to 6, the respondent was asked how representatives from Sales

are involved; and if the answer was 0, he or she was asked whether or not Sales involvement are

considered valuable. Furthermore, questions regarding how they would like to involve Sales in

the future and who they think should be responsible for Sales involvement were asked. Question

1 is illustrated in Table 4 Q1 Product Development below:

Table 3 Q1 Product Development

In question 2, the same questions were asked regarding the involvement of representatives from

the Installation function. Question 2 is illustrated in Table 5 Q2 Product Development below:

32


In question 3, the same questions were asked regarding the involvement of representatives from

the Service function. Question 2 is illustrated in Table 6 Q3 Product Development below:


In addition, the respondent was asked when a new developed product is considered as successful

and which targets they have for NPD. Question 4 and 5 is illustrated in Table 7 Q4-5 Product

Development below:

Table 6 Q4-5 Product Development

Sales, Installation and Service

In question 1, the respondent rated their functions level of involvement in NPD on a scale from

0 to 6. If the answer was 1 to 6, the respondent was asked how their function is involved; and if

the answer was 0, he or she was asked whether or not their involvement could be valuable.

Furthermore, questions regarding how they would like to be involved in the future and who they

think should be responsible for their involvement was asked. Question 1 is illustrated in Table 8

Q1 Sales, Installation and Service below:

33

Table 7 Q1 Sales, Installation and Service

In question 2, the respondent rated to what extent their functions inputs are taken into

consideration in the NPD process on a scale from 0 to 6. If the answer was 1 to 6, the

respondent was asked how their functions inputs are communicated; and if the answer was 0, he

or she was asked whether or not their inputs are considered as valuable. Furthermore, questions

regarding how they would like to communicate their inputs in the future and who they think

should be responsible for this were asked. Question 2 is illustrated in Table 9 Q2 Sales, Installation

and Service below:


In question 3, the respondent was asked how well the function fulfills their targets on a scale

from 0 to 6. If the answer was 0 to 5, the respondent was asked about the main reason for not

reaching their targets. This was of interest to identify the root-cause for not reaching their

targets. Question 3 is illustrated in Table 10 Q3 Sales, Installation and Service below:


In a questionnaire, it is also of importance to consider how much knowledge and experience the

respondent has on the subject. Therefore, question 4 was regarding how familiar the respondent

are with the Gateway process for NPD on a scale from 0 to 6. Question 4 is illustrated in Table

11 Q4 Sales, Installation and Service below:

34


5.1.2 Results from questionnaire

Product Development

In Table 12 Quantitative results PD, results from the quantitative part of the questionnaire is

presented as an average of all answers from Product Development. The average is calculated

from the sum of the answers on a scale from 0 to 6 and then divided by the number of

respondents.

Table 11 Quantitative results PD

Quantitative question Average

1. On a scale from 0 to 6, do you think that Sales representatives are involved in

the development of a new product?

3,05

2. On a scale from 0 to 6, do you think that Installation representatives are

involved in the development of a new product?

2,65

3. On a scale from 0 to 6, do you think that Service representatives are involved in

the development of a new product?

2,25

In Table 13 Qualitative results PD, the major findings from the qualitative part of the questionnaire

is presented. Additional answers are placed in Appendix A.

Table 12 Qualitative results PD

Qualitative questions - Major findings

If 1-6: How are they involved?

Sales give the marketing requirement to Product Manager. We develop the product according to MRS.

If 0: Do you think that their involvement could be valuable?

Yes, since then we can get feedback from them and improve/change/re-design the product so it

might be easier to sell. They also know the latest from our customer.

How would you like to involve them in the future?

Would be great for salesmen to have a portal where they could contribute digitally at their

convenience.

Who do you think should be responsible for Sales involvement?

Product Managers.


They are not. Sometimes they are part of testing the final/semifinal solution and give impact.


35

Yes, since they know what works and not works during the installation.


I think the right way is to go through the Product Management function, but perhaps through Design

for Installation workshops and involve R&D to understand what can/should be changed and then

create business cases for improvement in installation of our solutions.

Who do you think should be responsible for Installations involvement?

Product Management


I am not sure but my picture is that they are seldom involved. If they are involved it is because they

are active themselves in contacting product specialists for example.


This is critical to insure we keep number of tools down, training simple, van inventory and time at

sight to a minimum.


Would be great if they can be involved in the design phase.

Who do you think should be responsible for Service involvement?

Program Manager and Product Manager. However, responsible is not the same as having the contact

and setting up the meetings. This could be delegated. And with service it is very clear that the service

director should do a lot of work. The input needs to come from there.

When do you consider a new developed product to be successful?

When we can see that it fulfills the requirement that was set up when we decided to start the new

project. This does not only include technical requirement. It should off course include serviceability,

reliability, quality targets, installation time, unit cost and profitability. Some of these are really difficult

to put quantified and measurable targets to and that might be one reason why we fail on specifying

and measure requirements like quality and FOPS. It is easier to measure Unit Cost at GW4 than

FOPS at GW4.

Do you have any targets/KPI's for new Product Development? If so, which are they?

Product Innovation Process KPI, New Product Innovation

1. Organic Growth

2. New Product Ratio

3. Contr. Margin

4. SKU Development

5. Project leadership

6. Slip rate

7. Product mgmt.

8. Sustainability

9. Product Quality

Sales

In Table 14 Quantitative results Sales, results from the quantitative part of the questionnaire is

presented as an average of all answers from the Sales function. The average is calculated from

the sum of the answers on a scale from 0 to 6 and then divided by the number of respondents.

36

Table 13 Quantitative results Sales


1. On a scale from 0 to 6, do you think that your function is involved in the NPD? 2,33

2. On a scale from 0 to 6, do you think inputs on previous products are taken into

consideration in the NPD process?

1,33

3. On a scale from 0-6, how well do your function fulfill your targets regarding the

installation?

4,67

4. On a scale from 0-6, how familiar are you with the Gateway Process for NPD? 1,67

In Table 15 Qualitative results Sales, the major findings from the qualitative part of the

questionnaire is presented. Additional answers are placed in Appendix B.

Table 14 Qualitative results Sales


If 1-6: How are you involved?

I get questions about new products and I give input.

It often starts with questions regarding how much my team will sell.

If 0: Do you think that your involvement could be valuable?

Yes, I think the Sales or field staff involvement is absolutely necessary, because the sales team are

speaking each day with our customers who use our products daily.

How would you like to be involved in the future?

The sooner in the development of new products the better.

Who do you think should be responsible for your functions involvement?

Sales Manager and Product Management.

If 1-6: How do you communicate your inputs?

By talking to Product Management.

If 0: Do you think that your inputs could be valuable?

Of course, I think the inputs from the field are absolutely valuable, to know what the customers want,

what are new trends etc.

How would you like to communicate your inputs in the future?

Workshops, Skype, Meetings, Mail

Who do you think should be responsible for your functions inputs?

Sales Manager, Key Account Manager, staff with a huge technical knowledge.

If 0-5: What is the main reason for not reaching your targets?

Price strategy and lack of follow-up.

Installation

In Table 16 Quantitative results Installation, results from the quantitative part of the questionnaire is

presented as an average of all answers from the Installation function. The average is calculated

37

from the sum of the answers on a scale from 0 to 6 and then divided by the number of

respondents.

Table 15 Quantitative results Installation


1. On a scale from 0 to 6, do you think that your function is involved in the NPD? 1.18



2.27


installation?

2.64

4. On a scale from 0-6, how familiar are you with the Gateway Process for NPD? 1.27

In Table 17 Qualitative results Installation, the major findings from the qualitative part of the

questionnaire is presented. Additional answers are placed in Appendix C.

Table 16 Qualitative results Installation



No, we hear when there is a new product launched. Now for the first time we are involved in the new

revolver program.


Yes, for sure. Knowledge from the field is required to have a product that also could be installed and

serviced in an efficient and safe way.


Involve field Managers in process to offer insight into potential challenges with design aspects.


Product Manager/R&D department.


We have meetings/hotlines were people from our sales companies are involved.


For sure, practice experience valuable and not possible to mimic everything in a laboratory


Inputs should be given directly to R&D as a part of the gateway process.


Product Management.


Of course local organization issues should be improved, but also a lot product and supply chain issues

are related to this. For example the revolving doors quality at this moment has a big impact on the

operational cost in the sales companies. And if a product will be designed with more knowledge from

the field than Service and Installation can do their job in a more efficient way. And this will come back

in the results.

38

Service

In Table 16 Quantitative results Service, results from the quantitative part of the questionnaire is

presented as an average of all answers from the Service function. The average is calculated from

the sum of the answers on a scale from 0 to 6 and then divided by the number of respondents.

Table 17 Quantitative results Service


1. On a scale from 0 to 6, do you think that your function is involved in the NPD? 2.88



3,25


installation?

4,69

4. On a scale from 0-6, how familiar are you with the Gateway Process for NPD? 2,00

In Table 19 Qualitative results Service, the major findings from the qualitative part of the

questionnaire is presented. Additional answers are placed in Appendix D.

Table 18 Qualitative results Service



Service is not involved when new products are developed. And afterwards alterations are too

expensive.


Yes, we should learn to look at the total lifecycle of the door. And our revenue model.


I recommend an innovation for Service forum with top 3 Countries, Sweden/Holland and one more.


The Product Managers.


There are meetings to discuss problems of existing products, but smart solutions for new products are

not addressed.


Of course, but one should set up a communication platform, and not only focus on cost-reduction.


R&D team to visit countries- customers & collect local market info.


39

The Product Managers.


Solutions are developed and introduced locally, because of lack of international support. Products are

not developed specifically for service, even though service has to support the product for 15 years.

5.1.3 Open-ended interviews

Once the questionnaires were responded and summarized, people who were considered to be

able to contribute further to the thesis was selected for further interviews. These interviews were

conducted with an open-ended approach and the interviewee was allowed to talk without

restrictions, as long as, he or she stayed on topic. The interview process is described in the text

below and gathered information that are considered as valuable are highlighted in 5.1.4 Results

from open-ended interviews.

In the open-ended interview a presentation of the project were conducted as an introduction in

order to ensure that the interviewee understood the scope and later two, open-ended, main

questions were asked.

The agenda for the presentation of our project contains of following sections:

1. Necessary sections from the theoretical framework are firstly concisely described.

2. Problem statement.

3. The Gateway process

The interviewee was then asked regarding their role within the scope of our project and their

thoughts on involvement between NPD and other functions.

5.1.4 Results from open-ended interviews

Due to confidentiality reasons, the following parts cannot be published

5.2 Archive analysis

In order to further understand the situation at CXDY the authors collected information about

the current state by looking into the communicated material regarding processes, roles and

responsibilities, and organization.

5.2.1 Gateway process

The Company X Gateway process was developed by group management and is mandatory for all

Product Development projects. The process is divided into distinct stages or phases, separated

by decision points, known as gates. There are 6 gates that must be passed between project

40

initiation and post launch closure. The Gateway process is used to manage time to market and to

ensure business targets are achieved.

The Gateway process aligns all New Product Innovation activities and ensures a common way of

working with common approaches and a common language. By providing comprehensive

background data, the Gateway process ensure sound business decisions and traceability. All

business decisions in the Gateway process are made in the Product Council. As all necessary

functions are represented in the council, decisions in the Gateway process are aligned,

documented and characterized by a cross-functional way of working. The voice of the customer

represents the market needs and demands. The Gateway process is shown in Figure 17 Company

X Gateway process below:

Due to confidentiality reasons, the following figure cannot be published.

Each Gateway involves different activities and decisions. In order to fully understand the process

they are explained below:

0. Decision to invest in a requirement study. - Why should we do it?

The purpose of Gateway 0 is to motivate why the product should be developed and why

investments for a requirement study should be conducted. Among other things, this

gateway requires an initial business plan, a pre-study plan and a preliminary sales

brochure. The sales brochure will help you clearly define customer values.

1. Decision to continue to project specification. - What is the problem to solve?

Based on the requirement study, the purpose of Gateway 1 is to decide if the project

should continue to do a project specification. This gateway requires user stories, a more

detailed business plan, market requirement specification (MRS), risk assessment,

sustainability compass and a preliminary project plan. Before moving to Gateway 2, the

project plan should be approved, a project leader appointed and the project should be

given a priority.

2. Decision for project execution. - How do we solve the problem?

The objective of Gateway 2 is to decide if the project should be approved for execution.

This gateway involves finalizing the business plan, further developing the one pager and

setting up a visual project plan. The product requirement specification (PRS) will assure

that the project have enough knowledge, time and resources to guarantee success.

41

Output from this gateway are decisions to approve the project plan, CAPEX and to start

execution.

3. Decision to industrialize and communicate. - Can we start internal sales?

The goal of Gateway 3 is to decide if the organization should start preparing for

introducing the product to the market. Preparations include creating trust and confidence

within the organization as a preparation for launch. In this phase a product design

review, marketing finalization and launch plans are conducted. Also training plans for

Sales, Installation and support teams are drawn up. Decisions are taken to execute

industrialization and to communicate product announcement.

4. Decision to launch. - Can we accept orders?

The purpose of Gateway 4 is to approve production and launch of the product. This

requires market communication, product documentation, beta test reports, customer

feedback as well as a plan for transferring ownership from project to line organization

(New Product Innovation (NPI) to Continuous Product Innovation (CPI)). Also

confirmation from sales, production and sourcing are needed to assure operational

readiness. Output from Gateway 4 is approval for going to market and initiating sales.

5. Post launch review. - Is the product successful?

The final gateway involves reviewing the business case in retrospective. This includes

analyzing sales development, customer satisfaction, quality and cost. How previous steps

in the gateway process were conducted are also reviewed in order to improve future

execution. The final decision taken in the gateway process is to close the project.

The roles in the Product Development process, communicated by Company X, are Product

Managers, Line Managers and Project Leaders. Below a list of tasks, responsibilities and what is

expected for each role is presented:

Product Managers

o Deliver value to the business and play a strategic role in achieving this.

o Ensures business success of the product portfolio, from cradle to the grave

o Strategic, analytical and business oriented

Line Managers

o Owns the resources

42

o Ensure that resources have the right skills

o Knowledgeable in their field, make people grow

Project leaders

o Bring projects through the gateway process

o Remove impediments for their team

o Focused, high drive, product and execution oriented

This information can be translated into a flowchart that provides an overlook of how the

different roles interact in a project, see Figure 18 Interaction between role in Gateway process.

Figure 14 Interaction between roles in Gateway process

In addition to this information, documents that cannot be presented due to the non-disclosure

agreement between CXDY and the authors have been considered during the archive analysis. Of

these, different check lists for monitoring the progress and making decisions during the Gateway

process have been used in the analysis of sales, installation and service involvement in NPD.

5.2.2 Organizational charts

In order for the reader to fully understand the workways of CXDY the organizational structure

is presented in this chapter. The organization of CXDY top management is presented followed

by the organization of PS management, Product Development and local sales companies.

CXDY Management team

The Head of Division Y runs the division. Below this position a variety of support functions are

present. Also on this level the presidents for each business area are present. The presidents run

43

their businesses and report results to the Head of Entrance Systems. See organizational scheme

in Figure 19 Top management organizational chart.


PS Management team

This thesis is primarily concerned with the PS business area and therefore the PS management is

presented. As mentioned above all business areas are headed by the President. The organization

in the management team is similar to the top management organization. There are function

Managers and support function Managers present but instead of presidents there are area

specific Managers present. Since this thesis is evaluating the collaboration between Field

operations, Sales and Product Development the most important stakeholders are the Field

Operations Manager, Commercial Director and the Product Development Director. Also, the

president is of importance to this project since a commitment from top management is vital in

order to secure a change. See organizational scheme in Figure 20 PS management organizational chart.

Figure 15 PS management organization chart

Product Development

The different roles in the Product Development organization have different responsibilities

when new products are being developed. The organization is headed by the Product

Development Director, this role has the main responsibility for the organization.

44

The Product Managers are responsible for each product category, these categories are swinger,

slider and revolving doors. These Managers determines the demands on new products and

delivers these to the process. When a new project is initialized the responsibility of moving the

project through the Gateway process lays on the Project Managers. The projects are driven

through the Line Managers for each region and function where they are responsible for the

resources within each function. See organizational scheme in Figure 21 PD management

organizational chart.

Figure 16 PD management organization chart

Local sales companies

Sales, Installation and Service is carried out by the local sales companies. Here is where revenue

is created. The local sales companies are headed by the Business Unit Managers. In his or her

management team there are Sales, Installation and Service Managers. Also a complete finance

team is present which is headed by a controller. The Sales representatives are reporting to the

Sales Manager, Service technicians are reporting to Service Managers and Installation

representative’s reports to Installation Managers. The Field Operation Manager is follow up on

the business regarding installation and service in each country but is not responsible for the

individual which relies on the Business Unit Manager. See organizational scheme in Figure 22

Local sales companies organizational chart.

Figure 17 Local sales companies organization chart

45

6 Analysis

In this chapter, identified problem areas are presented before the current state is analyzed by using the theoretical

framework. This was done in order to establish a proposal for the future in the next chapter.

6.1 Identified problems in the current state

Through interviews, observations and archive analysis the authors have identified problems at

CXDY that are compiled in order to be analyzed and result in a proposal for the future.

Problems within the following areas were identified in the current state:

Consideration of other functions in NPD

The Gateway process

Concurrent engineering

Roles and responsibilities

Corporate culture

6.2 Analysis of identified problems

6.2.1 Consideration of other functions in NPD

According to Tonnquist (2012) a strategy for communication is of importance, especially in large

organizations. In the strategy, the best-suited communication channels as well as infrastructure

for the information flow needs to be determined in order to “ensure that the right target group

gets the right information at the right time and in the appropriate way”. Otherwise, the risk for

making mistakes that may upset stakeholders whom feel overlooked increases. (Ibid.)

It was realized in the interviews and by the author’s observations of the processes that there is a

lack of such a strategy for the inputs from other functions into the Product Development. Much

of the input are collected in an unstructured way and also in different ways depending on who is

collecting inputs. Here the authors realize that efforts must be put on setting up a structured way

of handling the inputs from other functions into the Product Development function, but also for

the other way around.

According to research done by Rasmus (2002) only 4 percent of the organizational knowledge is

stored and available in a structured way. The rest of the knowledge is unstructured or stored in

people’s minds. The authors have found a similar situation at CXDY by analyzing the interviews

and observing the business where a big knowledge gap in the organization has been identified.

Primarily knowledge is stored in people’s minds. This combined with a lack of a communication

46

strategy imposes a big discrepancy in the knowledge about the products and the market where

products are sold and interacted with by Internal and External Customers.

According to Ameri and Dutta (2005) organizations with an extensive knowledge management

system becomes more effective where knowledge is stored and managed. The knowledge

becomes easier to access and decisions are reinforced by using the updated knowledge from the

organization. The authors have found no such system at CXDY. Today the organization is using

a PDM system which focus heavily on the engineering data of the products. The system also

handles the change request process where issues of current products are being handled. No

system was found that handled the inputs to new Product Development. During the interviews

many interviewees expressed an interest in a system their thoughts on previous, current and

future products could be handled. This led the authors into the ideas of a PLM system. Such a

system could minimize product related cost, maximize product revenue, maximize value of

product portfolio and maximize value of current and future products for both end-users and the

enterprise (Stark, 2017).

According to Trott (2005), knowledge and information from other functions in the company

plays a key role in Product Development as a valuable input to the process. Depending on which

type of industry the company is present, inputs from one function may be more important than

another but it is important to consider all input. CXDY has a long value-chain which stretches

from Product Development to Sales, Installation and Service. It is of importance to consider the

three last functions which are the only ones which are creating positive cash flows. It is also of

major importance to make sure that when new products are developed, the products are easy to

sell, install and maintain. Then CXDY will sell more and perform installation and service in a

more efficient manner. Therefore also capturing a larger revenue stream and a better

contribution margin.

During the interviews with stakeholders from Sales, Installation and Service it was recognized

that these functions feel like their business are not taken into consideration by Product

Development. Products are rather developed according to only External Customer needs and it

is up to each sales company and Sales, Installation and Service organization to make sure that

their function is profitable.

Product Development can according to Trott (2005) be divided into two models; the

technology-driven model and the customer need-driven model. In the technology-driven model,

also referred to as technology push, scientists triggers the Product Development process by

making unexpected discoveries in their research. In the customer need-driven model, also

47

referred to as market pull, marketing triggers the Product Development process by identifying

market needs through interaction with customers (Ibid.). By combining these two models an

interactive model is achieved (Rothwell & Zegveld, 1985). In the interactive model innovation

has no specific trigger point and feedback is allowed through linkages between science base and

market place (Trott, 2005). Also, according to Trott (2005), inputs from organization capabilities

are required in the development of new products.

When the research by Trott (2005) on new Product Development is compared with the current

state at CXDY, the biggest difference is the ability of the Product Development function to

effectively involve other functions of the company in the development phase and develop

products that are appealing to both Internal and External Customers. Reasons for the lack of

involvement is primarily believed by the authors to be the deficiency of process support and

clear roles and responsibilities. The authors also believes that not viewing other functions in

CXDY as Internal Customers makes it difficult for the organization to see the need for

involvement of them. The new Product Development projects at CXDY always refer to the

“voice of the customer” (VOC) and tries to develop to satisfy their need, but never a “voice of

the Internal Customer” (VOIC) is mapped when new projects start.

When a new Product Development project is initiated the authors believe that the most

important thing is to have a set of demands outspoken that must be satisfied. If it is not realized

what should be solved in a project the how it’s going to be solved will be difficult. These inputs,

or “what’s”, of the project must be collected from both Internal and External Customers. This is

believed by the authors to be very important in a company which is not only selling their

products but also install and maintain the products on the aftermarket. Products must support

the demands of the External Customers, otherwise they will not buy the product. At the same

time the product must be easy to install and maintain to make sure that a healthy contribution

margin is sustained. So in short; the External Customer demands must be met in order to create

revenue, and the Internal Customer demands must be satisfied to sustain a good contribution

margin. Therefore, both Internal and External Customers’ demands must be satisfied.

6.2.2 The Gateway process

Products are never stopped in a Gateway

A problem that have been identified through interviews is that products almost never are

stopped in a Gateway today, which have resulted in several examples of products that are

released on the market but does not meet the requirements from stakeholders. Furthermore, this

have resulted in major costs for re-designing the products, as well as, increased costs for

48

installation and service of the products. This problem is considered to be connected to the

assertion that the product design influences the total cost of a product with between 70% and

85% (Dowlatshahi, 1992). Also, changes to product design not addressed in an early stage of

Product Development will create exponential costs in a later stage of the product lifecycle

(Bowersox, Closs, & Cooper, 2002).

In the archive analysis it is claimed that the Gateway process for Product Development is

divided into 6 different gates that are separated by decision points and must be passed between

project initiation and post launch closure.

The Gateway process is considered to be within the framework of traditional project

management since it include all three of the characteristics: planning and control, sequential

lifecycle stages and a more or less predictable process (Hass, 2007). In traditional project

management, Hass (2007) claims that planning and control is important in order to finish the

project on time and budget. The decision points used in the Gateway process is equivalent

tollgates, a tool which is used in purpose to control the outcome of each stage (Tonnquist, 2012).

A tollgate occurs after each gate, usually in meetings, where achieved project results are evaluated

and it is determined whether the project shall 1) continue, 2) go back, or 3) close (Ibid.).

According to the authors observations and interviews, the reason for why products never are

stopped in the Gateway process is not because project results always are fulfilled or because the

use of tollgates are not communicated; rather it has to do with the meetings where the action in a

tollgate is determined. In order to ensure that products are stopped in a Gateway if requirements

are not fulfilled it has to be determined which representatives to have in such a meeting and how

the decision is evaluated. Also, the authors believes that the corporate culture where the constant

pursuit for results are affecting this negatively. This notion is presented in more detail under the

chapter 6.2.5 Corporate culture.

In order to control the project, the Product Council consists of representatives from all

necessary functions (cross-functional) that is communicated from group management to be

responsible for all business decisions in the Gateway process. The Product Council is considered

by the authors to be equivalent to a Steering Committee. A Steering Committee has the

responsibility to control the project by reporting the status and progress and, in addition, a

Steering Committee shall be involved in the most important tollgate decisions (Tonnquist, 2012).

Since the Product Council is not involved in every Gateway decision, there will be Gateway

actions evaluated without a cross-functional team. This is a problem that lead the authors into

49

the idea of a Reference Group as a representative in the meeting to support the Program

Manager and Product Manager in Gateway decisions. A Reference Group consists of specialists

in what the project shall deliver and are responsible for giving advices on how the project can

meet the requirements and therefore can be considered as a support to the Project Manager, the

Steering Committee and the Project Owner (Hallin & Karrbom Gustavsson, 2012).

It was also realized that there is no structure in terms of meetings for Product Development and

involvement during the interviews and observations of the organization. Information gathered

contradicted what was communicated and vice versa. The authors believes that a new strategy

must be adopted in terms of meetings for Product Development and a more structured

approach must be adopted for handling the involvement of other functions.

Activities performed within each Gateway

In relation to inputs from interviews regarding Sales, Installation and Service earlier involvement

in the Gateway process, several examples of activities to involve them in was expressed. Among

them the following points are considered as the most important inputs:

Involvement in a prototype test and evaluation early in the project.

Involvement in a field test of the product performed early in the NPD project.

Perform training of technicians in Gateway 4.

Involvement in the design phase (Gateway 2-3) to offer valuable insights into potential

challenges.

These inputs are paired with activities in “The six phases of NPD process”, developed by Ulrich

and Eppinger (2015).

Highlighted activities from “The six phases of

NPD process” (Eppinger & Ulrich, 2015).

Functions to involve in NPD

Phase 0 – Planning

Phase 1 – Concept development

Construct and test demo types Installation and Service

Phase 2 – System level design

Identify service issues Installation and Service

Phase 3 – Detailed design

Phase 4 – Test and refinement

Testing of reliability, life and performance Installation and Service

50

Field testing Installation and Service

Train workforce Installation and Service

Create sales plan Sales

Phase 5 – Production ramp-up

Even though the phases within Ulrich and Eppinger (2015) model are not exactly equivalent to

how the Gateway process is constructed, the content is considered as valuable in order to

investigate in activities to involve Sales, Installation and Service in.

Product requirements

Through the archive analysis regarding the Gateway process Sales, Installation and Service are

claimed to have no regulated responsibilities to be involved in and evaluate the NPD process. In

Table 21 Gateway representatives below, a list of representatives who need to sign off the checklist

before closing a Gateway is presented:

Table 19 Gateway representatives

Project Team

Project Leader

Marketing responsible

R&D responsible:

Design engineer

Tooling engineer

Process engineer

Costing engineer

Production responsible

Sourcing responsible

Project Evaluators

General Manager

R&D or engineering Manager

Marketing Manager

Financial controller

Product Council Meeting

51

According to this, the authors interpret that it is communicated that representatives from Sales,

Installation and Service are not considered as a stakeholder who need to be involved and

evaluate each Gateway decision except from when the Product Council is involved in the most

important decisions.

In order to investigate this further, product requirements need to be analyzed. This is because

the authors consider that who to involve in activities and evaluation within the Gateway process

is related to who that was setting up requirements on the product in the beginning of the project.

This relation is because persons that had requirements on the product, by nature also wants to

follow-up the process and ensure that their demands are fulfilled.

In previous chapter 6.2.1 Consideration of other functions in NPD, the importance of utilizing the

wide range of perspectives from stakeholders with different experiences of previous products as

an input to NPD (Trott, 2005). Therefore, these inputs from External Customer, as well as, from

Internal Customer shall be prioritized and compiled into product requirements. Furthermore,

these requirements ends up in the assignment, or project goal, that is well-defined and specific

(Tonnquist, 2012).

Product requirements are further in line with the main characteristic of traditional project

management regarding the planning and control of the project (Hass, 2007). While setting up

product requirements, the authors consider it to be important to quantify them in e.g. numbers

and costs in order to easily measure them and follow-up. Quantified product requirements are

also considered by the authors to support Gateway decisions where achieved project results shall

be evaluated and the future of the project shall be determined.

To set up standardized product requirements for each product is considered by the authors to be

complicated because every project is unique. Nevertheless, the product lifecycle at CXDY is the

same regardless of product portfolio. Therefore, it may be an idea to set up standardized product

requirements with the purpose to ensure that inputs from other functions, especially Sales,

Installation and Service are taken into consideration when product requirements are evaluated.

Such a solution will ensure “The consideration of all downstream activities which are likely to

affect the product's lifecycle at the product’s design stage” (Pop-Iliev & Nokleby, 2011).

Product requirements are frequently mentioned by the interviewees as a problem in NPD.

According to the interviews, the working method with product requirements is somewhat

ambiguous since it occurs in several forms such as: market requirement specification (MRS),

52

User stories, a one-pager or sometimes all of them together. Nevertheless, the MRS is claimed to

be the most important document that shall work as a foundation for the project.

6.2.3 Concurrent engineering

The problem that has been commented to the greatest extent in the interviews concern that

Sales, Installation and Service are involved to late in the NPD process. Representatives from

these functions are considered to be involved in the test of the semifinal/final product. At this

point it is already too late since the product, regardless of their inputs, will be released on the

market. Apart from this, the Sales, Installation and Service functions are not involved regularly,

only when strong individuals from these functions show personal interest in the NPD process in

order to defend their demands on new products. Strong individuals from the Product

Development function may also contribute to the involvement of these functions where they

reach out to the functions. The involvement of other functions is therefore considered to be

dependent on people rather than processes.

Since the Gateway process is an integrated process, where different activities are overlapping

each other, several functions are involved in the process at the same time (Olhager, 2000).

According to this, CXDY has moved from a NPD model characterized by departmental stages

towards activity stages. Trott (2005) expressed the risk for the “over-the-wall” phenomenon even

though an NPD function changes towards an activity-stage model and according to observations

and interviews, the “over-the-wall” phenomenon is the major reason for the problems in NDP.

With the purpose to solve the problems, Crawford (1997) points on the importance of a cross-

functional team when activities are performed simultaneously in NPD. This led the authors into

the idea of concurrent engineering, which shortly is defined as “The consideration of all

downstream activities which are likely to affect the product's lifecycle at the product’s design

stage” (Pop-Iliev & Nokleby, 2011). In concurrent engineering the focus is switched once again

but now from individual stages to the entire project. The key to succeed with this change is

considered to be the involvement of all functions in the beginning of the project (Trott, 2005).

According to Bowersox et al. (2002), costs are higher and flexibility lower the longer down the

timeline a change is made. Therefore it is of importance to get input from downstream functions

and activities at an early stage so redesign is possible at a lower cost compared to when the

product has been launched.

It was realized during the analysis of interviews with Sales, Installation and Service function that

there is a lack of lifecycle thinking when new products are being developed. Designing for the

whole lifecycle the organization must think about what and how decisions affect other parts of

53

the business in the future (Kuo, Huang, & Zhang, 2001). If Product Development design

products that are hard to install or maintain on the field the local sales companies will have a

hard time sustaining the targets for installation and Service function regarding quality and time.

This is closely connected to the bottom line results of the sales companies, if installation and

service costs are too high, then the contribution margin will be too low.

6.2.4 Roles and responsibilities

Several inputs indicates that the view on the Product Manager’s responsibilities differ between

the interviewees and that this is claimed to cause problems in NPD. Among the comments a

majority indicates on different opinions in whether the Product Manager shall be responsible for

collecting and compiling information from all stakeholders and set up product requirements to

the project. According to the author’s observations, it is also vague at which point the

responsibility for the project shall be delegated from the Product Manager to the Program

Manager. Before these problems are analyzed, roles and responsibilities for the Product Manager

and the Program Manager will first be analyzed separately.

The Product Manager

According to the archive analysis, it is communicated that the Product Manager are responsible

for 1) deliver value to the business and play a strategic role in achieving this, 2) ensures business

success of the product portfolio, from cradle to the grave, and 3) strategic, analytical and

business oriented. Since those three points are rather vague, it is only the collected information

through interviews and authors observations that can define the current situation regarding the

Product Manager role and based on them it is claimed to be ambiguous.

The Product Manager role is equivalent to the Project Owner role. According to Tonnquist

(2012), the Project Owner shall:

Take the overall responsibility of the project outcome.

Allocate resources.

Ensure that the assignment, or project goal, is well-defined and specific.

Point 1 is connected with the three responsibilities specified in the archive analysis and is mainly

related to the fact that the Product Manager is responsible for the product portfolio results.

Point 2 is according to the archive analysis something that is primarily performed in Gateway 0

of the project. Point 3 is according to the archive analysis connected to Gateway 1 and is

considered as the source of why there are many thoughts on how and whom to specify the

requirements in the project.

54

The Program Manager

In the archive analysis, one of the roles communicated is the Project Leader. Early in the project

the authors realized that a Project Leader internally at CXDY is addressed as a Program Manager

which since then has been used.

To clarify roles and responsibilities, a Program Manager at CXDY is equivalent to a merge

between the Project Manager and a Program Manager according to the theoretical framework.

The role has a Project Manager approach since it has the responsible for managing the execution

function of the project by delivering a result that fulfills the project goal (Tonnquist, 2012). In

addition, the role also have typical characteristics for a Program Manager through the

responsibility to coordinate resources from Line Managers.

From the Product Manager to the Program Manager

According to the Tonnquist (2012), the responsibility for the execution of the project is

delegated from the Project Owner to the Project Manager when resources are allocated and the

assignment, or project goal, is well-defined and specific.

If those definitions are translated into what is communicated about the Gateway process in the

archive analysis, the Product Manager will have the overall responsibility in Gateway 0 and

Gateway 1 and then the project is delegated to the Program Manager in order to execute

Gateway 2 to Gateway 4. Before the project is closed and at least 12 months after Gateway 4,

Gateway 5 shall be executed which includes analysis of the project and product results such as

quality and customer satisfaction. According to authors observations and interviews, Gateway 5

is related to the problems analyzed in chapter 6.2.1 The information flow into NPD and whoever

that has the overall responsibility in this Gateway shall may be a combination of the Program

Manager and the Product Manager since the first execute the project and the last is responsible

for the product portfolio results.

In summary, roles and responsibilities for the Product Manager and the Program Manager need

to be specified. Primarily regarding product requirements since most comments was received

within this subject. How product requirements are evaluated and constructed was analyzed

further in 6.2.2 The Gateway process.

6.2.5 Corporate culture

Another aspect that was observed in this thesis was the corporate culture at CXDY. Historically,

there have been a mentality of cutting cost, one could argue that this has been the main focus.

55

The authors believes that this is one of the major factors for Company X’s constant growth and

good profit margin. The constant driver for growth and increase in profit margin is believed by

the authors to be connected to the listing of the company on Nasdaq OMX Nordic. Investors

expect the company to continue the growth and maintaining the profitability. This mentality is

built into the walls at the Division Ydivision as well. This way of conducting business is regarded

by the authors to be shortsighted and is not viewed upon as a working strategy for the future.

Additionally, the authors believes that this mentality contributes to the “we and them” mentality

identified at CXDY. The organization has built up imaginary walls between functions and sites

where everyone strives for local optima instead of a global optima or common goal. This is

closely connected to the “over-the-wall” phenomenon described by Trott (2005).

The constant strive for achieving better results also drive the constant hunt for reducing the head

count at CXDY. The authors has during through an analysis of interviews and observation of the

day to day business identified that the organization is suffering due to this. The issue of an

understaffed organization is that everyone always has to work reactive and never proactive. This

leaves little to no time for improving processes and ways of working. The authors strongly

believes that this approach satisfies short term goals but harms the organization in the long term.

The constant push for achieving better results is also harming the organization where all

functions are rushed to deliver their targets. This was observed by the authors and told by some

interviewees to be a contributor for the phenomenon that products are never stopped in a

Gateway. When the organization is rushed in this manner not only quality and performance is

harmed but the people of the functions as well.

Although the organization suffers from this constant pressure from top management the authors

have identified people whom are working with improving the processes and workways. These

are individuals that has initiated this work without proper support from management and they

are performing this on top of their normal workload. The authors believes that this work will

contribute in a positive manner, but in order to sustain change support must be given by top

management.

56

57

7 Future state

In this chapter, the authors will present the future state at CXDY. The future state is the result of the analysis

presented in previous chapter and shall be considered as a proposal on what to change in the short-term, as well as,

the long-term.

7.1 The proposed Gateway Process

In order to solve the problems identified in the analysis regarding the NPD at CXDY, a new

approach of the Gateway process is presented. The new process is believed by the authors to

primarily solve the problem that CXDY is not developing products for the Internal Customer.

By incorporating the Internal Customer as a stakeholder, equally important as the External

Customer, the authors believe that it will become easier to force a mentality where involvement

of other functions is mandatory or necessary in order to satisfy all demands to some extent.

As mentioned earlier in the report, the biggest difference between companies in the direct

channel at CXDY and in the rest of the Company X Group is the presence of Installation and

Service functions. The Gateway process therefore doesn’t consider the Internal Customers due

to this difference in the way of conducting business. Therefore, the authors believe it is of

outmost importance to change the process into a more suitable one where all Internal Customers

are considered.

The authors’ solution for the new process is built on the original Gateway process

communicated from the Group. The difference is primarily the introduction of the Internal

Customers as a stakeholder but there are also changes to the information flow, meetings, roles,

and responsibilities. This is presented in more detail in chapter 7.2 Roles and responsibilities, 7.3

Activities and 7.4 Concurrent engineering. Company X has previously presented the inputs from the

External Customer as the Voice of Customer, VOC. The authors have kept this input in the new

proposition but introduces the Internal Customers’ inputs as Voice of Internal Customer, VOIC.

The authors’ solution is presented schematically below in Figure 23 Proposed Gateway process, the

solution is also presented in a larger size in Appendix E.

58


7.2 Roles and responsibilities

7.2.1 The Internal Customer

The Internal Customer consists of all employees, from technicians to managers, within all

functions throughout the product lifecycle: Product Development, Supply chain, Manufacturing,

Marketing, Sales, Installation, Service, Finance and Legal. The Internal Customers are expected

to contribute with valuable information to NPD which is based on their knowledge and

experiences from interacting with previous and existing products. The Internal Customer is

proposed to be viewed as one of the company’s major strengths when new products are

developed, this is because inputs from Internal Customers can create business opportunities, as

well as, improve processes and as a result of this contribute to greater contribution margins.

7.2.2 The Reference Group and Function forums

According to the analysis, it is proposed to set up a Reference Group that is involved in the

NPD process. The Reference Group is suggested to be a cross-functional team that consist of

representatives from all functions throughout the product lifecycle: Supply Chain,

Manufacturing, Marketing, Sales, Installation, Service, Finance and Legal. The Reference Group

will represent the Internal Customers in NPD and its members are specialists from each function

with the main responsibility to give advices on how the project can fulfill the product

requirements.

Since the Reference Group represents all Internal Customers of CXDY, which in the proposed

future state shall contribute with inputs to NPD, it is also their responsibility to follow-up on

stated product requirements. According to this, such a Reference Group can contribute to

ensure that products that does not fulfill the requirements never passes a Gateway and therefore

are not released to the market. Furthermore, the cross-functionality of the team ensure that

decisions taken in each Gateway are taking the whole product lifecycle into consideration.

As mentioned earlier, CXDY is a global company that is performing business in several countries

with differences in e.g. market, regulations and culture. According to this, it is proposed to set up

one forum for each function with representatives from different countries. Each functions

59

forum are responsible to contribute with information based on their knowledge and experiences

from existing and previous products to their functions Reference Group member. In such a

solution, it is ensured that inputs from the Internal Customer are collected which is considered

to simplify the Reference Group members work in giving advices on how to fulfill product

requirements.

7.2.3 The Product Council

The Product Council is proposed to continuously act as a Steering Committee and will therefore

continue to focus on business decisions. In addition, the Product Council shall only be involved

in the most important Gateway decisions that risks to have a major impact on the business and

product portfolio results. Representatives within the Product Council will continuously consist

of one from each function in purpose to keep the cross-functionality. The Product Council will

also have the mandate to override any decisions taken in the project.

7.2.4 The Product Manager

According to the analysis, the Product Manager is proposed to take the overall responsibility of

the projects outcome. This is connected to the fact that the Product Manager is responsible for

the product portfolio results. In order to ensure that the assignment, or project goal, is well-

defined and specific, the Product Manager is also proposed to take the main responsibility for

setting up product requirements in Gateway 0. Furthermore, the Product Manager is considered

to be responsible for allocating resources to the project together with the Program Manager in

Gateway 1.

7.2.5 The Program Manager

When product requirements are stated and resources to the project are allocated, the main

responsibility for the project is proposed to be delegated from the Product Manager to the

Program Manager. The Program Manager is then responsible for coordinating resources from

Line Managers, as well as, managing the project team in order to deliver an outcome that fulfills

the product requirements that has been stated. The Program Manager will therefore be involved

in Gateway 1 and own the project from Gateway 2 to Gateway 4.

7.2.6 The Product and Program Manager

According to the analysis, both the Product Manager and the Program Manager need to take

their responsibility in Gateway 5 when the project and product results is analyzed and evaluated.

The purpose with this is to compile lessons learned and fallacies as an input to future projects.

60

In Table 22 Roles and responsibilities for Gateway 0 to 5 below, a summary of the Product and

Program Manager’s responsibilities is presented.

Table 20 Roles and responsibilities for Gateway 0 to 5

Role Responsibility Gateway

Product Manager The project outcome and the product portfolio

results.

GW 0-5, through the

Gateway meetings

Product Manager Set up product requirements and ensure that the

assignment, or project goal, is well-defined and

specific.

GW 0

Product Manager

Program Manager

Allocate resources to the project GW 1

Program Manager Coordinate resources from Line Managers

GW 2-4

Program Manager Responsible for managing the execution function of

the project in order to deliver a result that fulfills

the product requirements

GW 2-4

Product Manager

Program Manager

Evaluate the project and compile lessons learned

and fallacies as an input future projects.

GW 5

7.3 Activities

7.3.1 The Gateway meeting

It is proposed from the authors to set up a Gateway meeting. This is in order to ensure that the

fulfillment of product requirements are evaluated in each Gateway and ensure that the decision

in whether the project shall 1) continue, 2) go back, or 3) close is the best with consideration to

the whole product lifecycle. The representatives in such a Gateway meeting is proposed to be:

the Product Manager, the Program Manager and the Reference Group.

Even though the Product Manager has the overall responsibility for the project outcome, he or

she shall not have the right to take the Gateway decision without confirmation from the

participants in the Gateway meeting. In a scenario where one of the participants do not confirm

the proposed action in the Gateway decision, since he or she consider that it will affect the

business negatively, the Product Council shall be involved.

As a supporting tool to the project and Gateway meetings, the check lists previously used at

CXDY have been updated according to the proposed future state. This is in order to monitor

61

the progress of the project, enforce that right functions are involved and support the Gateway

decisions. All check lists are shown in Appendix F.

7.3.2 Inputs to NPD and Product requirements

It was found by the authors that the Internal Customers have inputs on the previous and existing

product range. Also, many functions have thoughts of what could be beneficial for new

products. The problem therefore, according to the authors, does not primarily lie in the creation

of requirements but rather in the way of communicating them to the Product Development

function. There are currently different meetings in which Product Development reaches out to

other functions and ask for their inputs, primarily regarding existing product portfolio. The

authors believes the effort is positive, but the lack of structure of the input and the lack of

structure for handling the input is deemed to be troublesome.

The nature of the input is, according to the authors, also believed to be very important. The

inputs must be quantifiable in order for Product Development and other stakeholders to

determine whether a product is successful or not. It will also make it easier in order to follow up

the project and take decisions during Gateway meetings regarding the fulfillment of product

requirements.

Although the requirements on new products may vary from one project to another, the authors

believes that a set of standard requirements would be beneficial. The standard requirements are

constructed by interpreting the KPI’s of Sales, Installation and Service and are translated into

quantifiable inputs. If this is adopted by CXDY the Product Development will, in the long-term,

learn that products have to be developed within these requirements. In other words, these

standard requirements will ensure that products are designed with consideration to all

downstream activities. According to the authors design for Sales, Installation and Service is

especially important in the current state at CXDY. Therefore, a suggestion for standard

requirements are presented in Appendix G.

While the requirements of the Internal Customers are important, the demands of the External

Customer are equally important. If the products of CXDY does not appeal to them they would

not buy them, and the business is gone. At the same time products that does not satisfy the

requirements of the Internal Customer will make it harder to reap a good enough profit margin.

Here, the authors believes that the Product Manager at CXDY must be the balancer between the

two.

62

Product requirements from both Internal and External Customers are balanced and compiled by

the Product Manager in the future state. Progress in the development project must then always

be compared to the demands set in the beginning and therefore ensuring that progress stays on

the right path.

In order to efficiently handle the inputs, the authors propose the implementation of a PLM

system. Such a system would also give the organization a much better picture on how products

are performing during the whole lifecycle. Although, implementation of such a system could be

expensive. Today, CXDY has a PDM system implemented with the possibility of setting up

processes. The authors propose to delay the investment into a new PLM system and focus on a

short-term solution where inputs to product development are handled in the current PDM

system.

After the implementation of a more structured way of handling the inputs from all stakeholders

the authors believes that new products will be more profitable. The product requirements will act

as steering for the development processes and progress will always be compared to the

requirements. This will also contribute to an easier follow-up of quantified data or knowledge.

7.3.3 Activities to implement

It is proposed by the authors to implement some activities that is considered as critical in order

to involve Sales, Installation and Service in NPD. According to the authors, the proposed future

state with changes in the information flow, meetings, roles, responsibilities and stakeholders is

predicted to generate similar activities in the long-term in order to create successful products.

Nevertheless, following activities identified in the analysis are considered as valuable to

implement and are therefore highlighted by the authors:

Product prototypes shall be constructed and tested in Gateway 3.

Potential installation and service issues shall be identified in Gateway 3.

A field test of reliability, life and performance shall be performed in Gateway 3.

Training of Installation and Service technicians shall be performed in Gateway 4.

7.4 Concurrent engineering

As mentioned in the analysis, the involvement of all functions in the beginning of the NPD

project is critical. This is primarily because the product design has a major impact on the total

63

cost of a product since product changes not addressed in an early stage of Product Development

will create exponential costs in a later stage of the product lifecycle.

Therefore, the authors propose to involve all functions in the beginning of the project where

product requirements are confirmed and the product design is developed. Then the level of

involvement in terms of activities and responsibilities in the process may vary from one function

to another throughout the NPD project. To ensure that requirements from e.g. Marketing are

evaluated during a Gateway decision even though their level of involvement in that Gateway was

low; it has already been proposed to include a member from the Marketing function in the

Reference Group.

In concurrent engineering the focus is switched from individual stages to the entire project. As

illustrated in Figure 24 Level of involvement in NPD, all functions are involved in the NPD project

even though the level of involvement may vary from one Gateway to another.

Figure 18 Level of involvement in NPD

64

65

8 Discussion and future recommendations

In this chapter, the presented solutions from the Future state are discussed. Also, the areas where the authors

believe more research could be beneficial are presented. The chapter is divided into the two-sided purpose of the

thesis where inputs to NPD and involvement in NPD from other functions are discussed separately as well as a

discussion regarding the corporate culture at CXDY.

8.1 Contribution

The outcome of this thesis includes contribution to CXDY as well as research within the scope

of Product Development and Project Management and is expected to, as a whole, answer to the

purpose of this thesis:

“The purpose of this thesis is to propose a solution for how to coordinate information flow to NPD and how to

increase the level of involvement from other functions into the NPD process.”

The main contribution to CXDY is the proposed future state. In a scenario where the proposed

future state is implemented at CXDY, this is claimed to bring the company closer to one of their

main visions:

“To lead in innovation and provide well-designed, safe, secure and convenient solutions that give true added value

to customers”

Nevertheless, the outcome of this thesis is also expected to contribute to research. Primarily, this

is done through the collection of data regarding how CXDY, as a large and global industrial

actor, is conducting business. Even though the proposed future state is related to the current

circumstances at CXDY, it has its foundation in the theoretical framework. According to this,

the thesis is considered to contribute to future research studies on companies with comparable

problems and phenomenon’s as CXDY. That is to say, an industrial company which is

experiencing a similar situation and operating with a product lifecycle that includes Product

Development, Sales, Installation and Service.

Furthermore, the major findings in this thesis are considered to be a contribution to research

itself, but also, a contribution to future researchers since suggestions for this is highlighted in this

chapter. Primarily, these suggestions are related to investigations in whether identified gaps

between the theoretical framework and how the business actually is conducted are general

problems or not.

66

8.2 Inputs to the NPD Process

As mentioned earlier the trigger for NPD could be either push, where a new function or feature

is developed which is not yet a demand from customers, or pull where a customer asks for a

specific function or feature and which is developed accordingly. When the demands of the

customer, which in this thesis was divided into internal and external, were compared it was

realized that the nature of the demands differ. The demands of the external customer are

considered to be basic function related. The customer wants doors that opens and closes as

cheap as possible. Also, the operators must meet the regulatory demands of the country where it

is installed regarding fire, security and safety. These demands are somewhat similar to the

demands of the sales function where they are not able to sell if the products do not fulfill these

requirements. However, the demands of the Internal Customer are related to the ease of

handling the operators, primarily regarding installation and service.

The authors believes that the difference in the demands from Internal and External Customers

are not contradictory to each other. This is important for the organization to understand. When

new products are developed, the basic functions should be obvious and satisfied. Efforts must

also be put on developing products which satisfy the demands of the Internal Customer. If both

are satisfied the authors are confident that costs related to installation and service will be lower

and a larger contribution margin will be captured which will result in overall better results.

The authors has realized during this thesis that there is a lack of a holistic view throughout the

organization and processes. Functions, and people within them, do not understand that changes

in one place will affect other functions downstream. This could also be called a lack of lifecycle

thinking or concurrent engineering. The authors believe that with an implementation of the

presented new process, activities and new roles and responsibilities will force the organization to

consider all functions. These solutions will also force the function which has set up demands to

ensure that their requirements are satisfied.

The requirements of the Internal Customer, or VOIC, must be presented to the Product

Development function in a structured and quantifiable way. In order to secure this the authors

proposed forums for each function which feeds the Reference Group with inputs. The inputs

are filtered first in the forums and then in the Reference Group in order to deliver tangible and

comparable requirements for Product Development. If this is not done properly the authors

believes that the requirements are not fulfilled.

67

This thesis has focused on the inputs from Sales, Installation and Service function. However,

other functions might have more requirements on the products that are being developed. The

authors propose that further research is conducted regarding mapping other functions and their

inputs. This must be done in order to ensure concurrent engineering for the organization as a

whole. Only when all functions are harmonized and involved in all activities will CXDY exploit

all the gains of concurrent engineering.

8.3 Involvement in the NPD Process

Throughout the development of this thesis it has been realized that the “garbage in, garbage out”

principle has brought the two-divided purpose closer together. One of the common

denominator for this is product requirements. This is because inputs from Internal Customers to

NPD shall be compiled into product requirements, but also, all functions shall be involved when

product requirements are stated.

Nevertheless, the involvement of all functions in the beginning of the NPD project is claimed to

be one of the most important changes in order to develop products with consideration to all

downstream functions at CXDY. This is not only because the critical activity to set up product

requirements is performed in the beginning of the project but also because the product design is

determined there. The understanding that all functions shall be involved, more or less,

throughout whole NPD process is in the theory referred to as the concept of concurrent

engineering. According to the authors, it is a gap between the theory of concurrent engineering

and how NPD projects are performed today at AEES. This led the authors into a

recommendation for future research; investigate and compare the presence of concurrent

engineering in NPD at a company similar to CXDY.

In traditional project management, tollgates are a common-used tool in order to meet the

product requirements and develop new products that are profitable throughout the entire

product lifecycle. Tollgates are used applied in the Gateways at CXDY and is considered by the

authors to be a problem. The problem was identified through the data collection when it was

realized that products almost are never stopped in Gateways, which indicates that tollgates are

not used according to the theory. The result of this problem is costly since product that does not

fulfill the requirements are released on the market. The proposed solution presented by the

authors was to set up a cross-functional Reference Group that must confirm every tollgate

decision before products can continue to the next Gateway. A recommendation for future

research is to look into this further. Tentatively, at another company that is using tollgates in

68

their NPD process in purpose to investigate in whether this is a general problem or not and,

furthermore, come up with new solutions.

It is mentioned earlier that the proposed future state at CXDY is predicted to force Product

Development to come up with different NPD activities in order to fulfill product requirements.

This prediction is primarily based on two conditions:

That quantitative requirements and a set of standard requirements from Internal and

External Customers are considered.

That the new Gateway meeting where tollgate-decisions are correctly determined is

implemented.

Even though such activities are predicted to be generated through the proposed future state

some of them have been identified by the authors. Namely; 1) construction and test of product

prototypes, 2) field test of the product, and 3) training of Installation and Service technicians.

How to set up these activities, who to involve and what to do is also a recommendation for

future research.

8.4 Corporate culture

According to the authors, the presented changes to the workways and processes will contribute

to a new better future state. A state in which products are satisfying the requirements of all

customers, internal and external, and where all functions are involved in NPD.

The corporate culture at CXDY may be a threat to the implementation of the presented

solutions. Primarily regarding time where change management needs a lot of it in order to sustain

a change. The constant reactive, and never proactive, work is damaging the business where time

is never given to analyze workways and processes. The authors believes that this is due to the

constant drive to reduce cost and achieve growth which introduces a time pressure to the

organization as a whole. This state of the business, or culture, also contributes to the “we-and-

them” or ”over-the-wall” phenomenon which is mentioned earlier. No strategy can be effectively

implemented without a culture which supports it. Said in its simplicity by Mark Fields (2006):

“You can have the best plan in the world, and if the culture isn’t going to let it happen, it’s going to die on the

vine” –Mark Fields (2006)

69

9 Table of References

Acharya, A. S., Prakash, A., Saxena, P., & Nigam, A. (2013). Sampling: Why and how of it. Indian Journal of

Medical Specialties, 4(2), (pp. 330-333).

Ameri, F., & Dutta, D. (2005). Product lifecycle management: closing the knowledge loops. Computer-

Aided Design and Applications, 2(5), 577-590.

Company X. (2017). Annual Report. Company X.

Company X. (2018, 02 06). Company X Group websites. Retrieved from Company X Group websites:

xxxxxxxxxxxxxxxxxxxxxxxxxxx

Blomkvist, P., & Hallin, A. (2015). Method for engineering students: Degree projects using the 4-phase Model.

Studentlitteratur.

Boothroyd, G., & A. L. (1992). Design for assembly and disassembly. CIRP Annals-Manufacturing

Technology, 41(2), (pp. 625-636).

Boothroyd, G., & Dewhurst, P. (1986). Product Design: Key to Successful Robotic Assembly. Assembly

Engineering, 29, (pp. 28-31).

Bowersox, D. J., Closs, D. J., & Cooper, M. B. (2002). Supply chain logistics management (Vol. 2). New York,

NY: McGraw-Hill.

Brennan, L., Gupta, S., & Taleb, K. (1994). Operations planning issues in an assembly/disassembly

environment. International Journal of Operations & Production Management, 14(9), (pp. 57-67).

Cambridge Dictionary. (2018, March 13). Cambridge Dictionary: English Dictionary. Retrieved from

Cambridge Dictionary: https://dictionary.cambridge.org/dictionary/english/

Carter, D., & Baker, B. (1992). Concurrent Engineering: The Product Development Environment for the

1990s. Addison-Wesley, Reading, PA.

Crawford, C. (1997). New Products Management, 5th edn. Chicago, IL: McGraw-Hill.

Dowlatshahi, S. (1992). Product design in a concurrent engineering environment: an opti- mization

approach. Journal of Production Research, 30 (8), (pp. 1803-1818).

Eppinger, S., & Ulrich, K. (2015). Product design and development. McGraw-Hill Higher Education.

Fiksel, J., & Wapman, K. (1994). How to design for environment and minimize life cycle cost. In

Electronics and the Environment. 1994 IEEE International Symposium (pp. 75-80). IEEE 1994.

Ford, R. C., & Randolph, W. A. (1992). Cross-functional structures: A review and integration of matrix

organization and project management. Journal of management, 18(2), (pp. 267-294).

70

Hallin, A., & Karrbom Gustavsson, T. (2012). Project Management. Malmö: Ola Håkansson.

Harjula, T., Rapoza, B., Knight, W., & Boothroyd, G. (1996). Design for disassembly and the

environment. CIRP Annals-Manufacturing Technology, 45(1), (pp. 109-114).

Hass, K. B. (2007, May). The Blending of Traditional and Agile Project Management. Project Management

World Today, Vol. IX, Issue V.

Horvath, A., Hendrickson, C., Lave, L., & McMichael, F. (1995). Performance measurement for

environmentally-conscious manufacturing. Manufacturing Science and Engineering, 22, (p. 885).

Hsuan, J., Skjøtt-Larsen, T., Kinra, A., & Kotzab, H. (2015). Managing the global supply chain. Copenhagen

Business School Press.

Höst, M., Regnell, B., & Runesson, P. (2006). Att genomföra examensarbete.

Jacobsen, D. I., Thorsvik, J., & Sandin, G. (2014). Hur moderna organisationer fungerar.

Jovane, F., Alting, L., Armillotta, A., Eversheim, W., Feldmann, K., Seliger, G., & Roth, N. (1993). A key

issue in product life cycle: disassembly. CIRP Annals-Manufacturing Technology, 42(2), (pp. 651-658).

Kapoor, K. C., & Lamberson, L. R. (1977). Reliability in engineering design. John Wiely and Sons.

Kirkland, C. (1988). Meet two architects of design-integrated manufacturing. Plast. World, 46(12), (pp. 44-

45).

Kuo, T., Huang, S., & Zhang, H. (2001). Design for manufacture and design for ‘X’: concepts,

applications, and perspectives. Computers & industrial engineering 41(3), 241-260.

Maffei, A. (2017). Assembly Technique. Stockholm: KTH Royal Institute of Technology.

Maltzman, R., Rembis, K. M., Donisi, M., Farley, M., Sanchez, R. C., & Ho, A. Y. (2005). Design for

networks—The ultimate design for X. (pp. 5-24). Bell Labs Technical Journal, 9(4).

Miao, Y. J., & Chen, H. M. (2011). Innovation and new product development management. Advanced

Materials Research (Vol. 156) (pp. 1578-1581). Trans Tech Publications.

Olhager, J. (2000). Produktionsekonomi. Institutionen för produktionsekonomi.

Pop-Iliev, R., & Nokleby, S. B. (2011). Concurrent approach to teaching concurrent design engineering.

Proceedings of the Canadian Engineering Education Association.

Rasmus, D. (2002). Collaboration, contents and communities, an update. Giga Information Group Inc.

Rothwell, R., & Zegveld, W. (1985). Reindustrialisation and Technology. Longman.

Stark, J. (2017). Product Lifecycle Management (Vol. 3): The Executive summary. Springer.

71

Tonnquist, B. (2012). Project Management: A Guide to the Theory and Practice of Project, Program and

Portfolio Management and Organizational Change. Sanoma utbildning, Stockholm.

Trott, P. (2005). Innovation management and new product development. Pearson education.

Winner, R. I., Pennell, J. P., Bertrend, H. E., & Slusarczuk, M. M. (1988). The Role of Concurrent

Engineering in Weapons System Acquisition. IDA Report R-338. Alexandria, VA: Institute for

Defence Analyses.

72

73

10 Table of figures

Figure 4 Adopted from (Ameri & Dutta, 2005): PLM system overview .......................................................... 12

Figure 5 Adopted from (Ameri & Dutta, 2005): Learning capacity .................................................................. 12

Figure 6 Adopted from (Ameri & Dutta, 2005): Cash flow ............................................................................... 13

Figure 7 Adopted from (Ford & Randolph, 1992): Matrix organizational structure ...................................... 14

Figure 8 Adopted from (Hallin & Karrbom Gustavsson, 2012): Functions and roles in a project ............. 16

Figure 9 Adopted from (Trott, 2005): Product Development and the design environment......................... 18

Figure 10 Adopted from (Rothwell & Zegveld, 1985): The interactive model of innovation ...................... 19

Figure 11 Adopted from (Olhager, 2000): Integrated Product Development process .................................. 20

Figure 12 Adopted from (Eppinger & Ulrich, 2015): The six phases of NPD process ................................. 22

Figure 13 Adopted from (Trott, 2005): Cash flow throughout a product lifecycle ........................................ 22

Figure 14 Adopted from (Crawford, 1997): An activity-stage model................................................................ 23

Figure 15 Adopted from (Bowersox, Closs, & Cooper, 2002): Flexibility and cost of changes ................... 24

Figure 16 Adopted from (Höst, Regnell, & Runesson, 2006): The triangular approach ............................... 26

Figure 18 Interaction between roles in Gateway process .................................................................................... 42

Figure 20 PS management organization chart ....................................................................................................... 43

Figure 21 PD management organization chart ..................................................................................................... 44

Figure 22 Local sales companies organization chart ............................................................................................ 44

Figure 24 Level of involvement in NPD ............................................................................................................... 63

74

75

11 Table of tables

Table 2 Adopted from (Eppinger & Ulrich, 2015): The six phases of NPD process .................... 20

Table 3 Adopted from (Blomkvist & Hallin, 2015): Qualitative and quantitative .......................... 28

Table 4 Q1 Product Development ......................................................................................................... 31



Table 7 Q4-5 Product Development ..................................................................................................... 32

Table 8 Q1 Sales, Installation and Service ............................................................................................ 33

Table 9 Q2 Sales, Installation and Service ............................................................................................ 33

Table 10 Q3 Sales, Installation and Service .......................................................................................... 33

Table 11 Q4 Sales, Installation and Service .......................................................................................... 34

Table 12 Quantitative results PD ........................................................................................................... 34

Table 13 Qualitative results PD .............................................................................................................. 34

Table 14 Quantitative results Sales ......................................................................................................... 36

Table 15 Qualitative results Sales ........................................................................................................... 36

Table 16 Quantitative results Installation .............................................................................................. 37

Table 17 Qualitative results Installation ................................................................................................ 37

Table 18 Quantitative results Service ..................................................................................................... 38

Table 19 Qualitative results Service ....................................................................................................... 38

Table 21 Gateway representatives .......................................................................................................... 50

Table 22 Roles and responsibilities for Gateway 0 to 5 ...................................................................... 60

76

12 Appendix

12.1 Appendix A

Due to confidentiality reasons, the table cannot be published.

12.2 Appendix B


12.3 Appendix C


12.4 Appendix D


12.5 Appendix E

Due to confidentiality reasons, the figure cannot be published.

12.6 Appendix F


12.7 Appendix G


www.kth.se

Documents

Consideration of downstream functions in New Product