Managing complex product development projects
HELEN GHATTAS
Hantering av komplexa produktutveklingsprojekt
HELEN GHATTAS
Examensarbete
Stockholm, Sverige 2016
Hantering av komplexa produktutvecklingsprojekt
- Ett analytiskt ramverk för komplex produktutveckling
Helen Ghattas
Examensarbete INDEK 2016
KTH Industriell teknik och management
Managing complex product development projects
- An analytical framework for complex product development
Helen Ghattas
Master of Science Thesis INDEK 2016 KTH Industrial Engineering and Management
Industrial Management
SE-100 44 STOCKHOLM
Examensarbete INDEK 2016:113
Hantering av komplexa produktutvecklingsprojekt
Helen Ghattas
Godkänt
2016-06-16
Examinator
Thomas Westin
Handledare
Anna Jerbrant
Uppdragsgivare
Maskinkonstruktion
Kontaktperson
Martin Grimheden
Sammanfattning
Under de senaste åren har produkterna blivit mer invecklade beträffande anslutningen, prestanda och funktionalitet. Därför är syftet av denna studie att undersöka hur komplexa system utvecklas och leds genom att genomföra fallstudie på olika svenska företag som utvecklar mekatroniska och cyber-fysiska system.
Resultatet av denna studie har lett till identifieringen av många utmaningar som de undersökta företagen har och som i sin tur har lett till framställningen av ett analytiskt ramverk som diskuterar hur och vad man bör göra för att utveckla komplexa produkter på ett effektivt sätt, så att onödig komplexitet i produktutvecklingen kan reduceras.
Nyckelord: Cyber-fysiska system, integrationsfasen, V-modellen, projektledning,
Managing complex product development projects
Helen Ghattas
Approved
2016-06-16
Examiner
Thomas Westin
Supervisor
Anna Jerbrant
Commissioner
Machine Design
Contact person
Martin Grimheden Abstract
In recent years, products have become more complex in terms of connectivity, performance and functionality. Therefore, this study aims at studying how complex products are developed and managed through conducting multiple case studies at different Swedish companies that develop mechatronic or cyber- physical systems.
The results of this study is the identification of many challenges that the investigated companies have, which have led to a presentation of an analytical framework that discusses how complex product development projects can and should be managed in order to be efficient, in order to reduce unnecessary complexity in the way companies develop these complex products.
Keywords: Cyber-physical, integration phase, V-model, project management,
product development, mechatronics and systems engineering (SE).
I would like to thank Martin Grimheden for both being an excellent thesis project owner and supervisor. Thank you for providing me with the essential equipment and for involving me in the department that turned up to be like drinking from a firehouse. Also, your decision to give me freedom to investigate new areas and your support of my ideas has made this work enjoyable.
I would like to extend my deepest gratitude to my head supervisor Anna Jerbrant for your guidance and support during these last months in which you always succeed to put me back on course whenever I turned up at your office clueless. Your deep and broad knowledge meant that I could discuss many things with you and for this work I most certainly needed that.
I would like to thank Martin Törngren for taking an interest in my work, which meant that I gained more and more knowledge until I reach a point where I thought I have learnt everything, but then I was just fooling myself. Thank you for being a constant source of information and inspiration.
I would like to show my sincere appreciation for Carl During, whose involvement took my work to another level. Thank you for so voluntarily deciding to help me, for explaining some aspects that I did not consider or understand, and for setting up meetings with relevant people.
As time is of the essence during any thesis work, I would like to thank my parents for understanding, taking the time to proofread my work, and for their continuous supply of nutritious food that is quite a contrast to the standards one gets used to during five years of university life.
Lastly, I would like to show my gratitude to all who have directly or indirectly, empirically or
theoretically, through formal bi-weekly meetings or during lunch breaks, contributed to my
thesis’ creation and development.
Table of Contents
1 Introduction to the Research Field 9
1.1 Background . . . 9
1.2 Problematization . . . 10
1.3 Research Aim and Objective . . . 11
1.4 Research Question . . . 11
1.5 Delimitations . . . 11
1.6 Thesis Motivation . . . 12
1.7 Reader’s Guide and Overall Findings . . . 12
2 Methodology 15 2.1 Literature Study - Planning and Developing . . . 15
2.2 Design of Case Study . . . 17
2.3 Research Methodology . . . 18
2.4 Empirical Data Collection . . . 19
2.5 Cross-Case Analysis . . . 20
2.6 Analytical Framework . . . 21
2.7 Method to Verify the Analytical Framework . . . 21
2.8 Ethics . . . 22
2.9 Limitations set by the Research Method . . . 22
2.10 Validity and Reliability . . . 23
3 Frame of Reference 25 3.1 Complex Systems . . . 25
3.1.1 Cyber-Physical Systems . . . 25
3.1.2 Mechatronic Products . . . 26
3.2 Complex Product Development . . . 27
3.2.1 Three Product Development Domains . . . 27
3.2.2 Life Cycle Stages . . . 28
3.2.3 Modular and Integrative Systems . . . 28
3.2.4 Design Structure Matrix (DSM) . . . 29
3.2.5 Technical Dependencies . . . 30
3.2.6 Virtual Environments . . . 30
3.2.7 Model-based Language . . . 31
3.3 Project Management . . . 32
3.3.1 Project Management Phases . . . 34
3.3.2 Agile Methods . . . 35
3.3.3 Project Success Criteria . . . 36
3.4 Systems Engineering . . . 37
3.4.1 Systems Engineering Processes and Activities . . . 38
3.4.2 V-model . . . 39
4 Results 41 4.1 Empirical Background . . . 41
4.1.1 Cases Investigated . . . 41
4.1.2 Analysis Process . . . 44
4.2 Empirical Findings . . . 45
4.2.1 Project Management Challenges . . . 45
4.2.2 Complex PDP Challenges . . . 48
4.2.3 Systems Engineering Challenges . . . 52
5 Discussion 59 5.1 Analysis Process . . . 59
5.2 Analytical Framework . . . 59
5.2.1 Pair Concept fundamental for PDP . . . 59
5.2.2 More emphasises on Integration Phase . . . 62
5.2.3 A new view of the V-model . . . 65
5.3 Practical Contribution and Sustainability . . . 68
5.4 Theoretical Contribution . . . 68
6 Conclusion 69 7 Future Work 71 8 Appendix 78 8.1 Appendix A: Case Study . . . 78
8.1.1 List over Participants’ role description . . . 78
8.2 Appendix B: Literature List . . . 88
8.3 Appendix C: List of Codes . . . 92
8.3.1 Description of Systematic Coding . . . 92
8.3.2 List of codes for Managerial Challenges . . . 93
8.3.3 List of Codes for Technical Challenges . . . 93
8.3.4 List of Codes for Solutions of Technical Challenges . . . 94
List of Figures
1 Designers with different engineering backgrounds have different view of the same product. Figure taken from Malvius [28] . . . 102 The iterative work process of this thesis . . . 15
3 The abductive approach highlighted . . . 16
4 General architecture of a CPS, where the computing and communication capabilities are integrated with the monitoring and control entities in the physical world. Figure taken Cardenas et al. [24] . . . 26
5 Generic life cycle model. Adapted from (ISO/IEC/IEEE 15288) and (ISO/IEC 24748) [44] . . . 28
6 Generic project life cycle stages and project model for product development. Figure adapted from [33] . . . 32
7 Project phases according to Maylor [32] . . . 33
8 A V-model presentation taken from SEBoK [49] . . . 39
9 Hierarchical order in a project . . . 42
10 A product in Mycronic is regarded as a system that is decomposed into functions that different projects are responsible for developing. The projects differ in both size and type . . . 43
11 Developing hardware for software as a new way to reduce integration problems 43 12 Illustration of product decomposition. The numbers show the estimation of human resources at each sub-system/function. . . 46
13 The V-model adapted from [49]: The high-level design is where defined requirements and specification about the subsystem are set . . . 47
14 Product decomposition types . . . 49 15 Integration plan followed to show when projects have to deliver their parts . 52
16 Parallel and temporary organisation in a project and the teamwork between a project manager and technical manager in complex PDP. The terminology
is specific for Mycronic . . . 55
17 Development approach in some projects of complex PDP . . . 57
18 The generic project life cycle with a very notable stage added for PDP . . . 64
19 The V-model with a risk for becoming a U-model . . . 66
20 The conceptual framework used in the formation of the case study ques- tioneer. Strategy inspired from Yin [9] . . . 81
21 Scope of the thesis and conceptual framework formation . . . 82
22 The work protocol of the case study used. Figure adapted from Yin [9] . . . 83
23 CPS’ dimensions of complexity. Figure taken from [45] . . . 91
24 Coding of the interview transcripts . . . 92
List of Tables
1 List of conducted interviews . . . 202 List of experts interviewed during the analysis . . . 22
3 Description of participants . . . 44
4 C.1: Managerial challenges in PDP . . . 93
5 C.2: Technical challenges in PDP . . . 94
6 C.3: Industrial solutions . . . 94
Glossary
analytical framework This term means a project framework that is the result of the analysis of the empirical findings and literature study done in this thesis.. 12
concept and feasibility phase the phase starts with an exploratory approach in order to study new ideas and technology and provides a risk and opportunity assessments, budget and schedule [44] . 10
continuous integration a software development method that has in recent years gained in popularity. The aim of the method is to prevent the integration process of software development from becoming a complex, uncertain and time-consuming process [47].
55, 67
cyber-physical system according to Cyber-Physical European Roadmap and Strategy (CyPhERS), which is co-founded by the European Commission to develop a Euro- pean strategic research and innovation agenda for cyber-physical systems (CPS) in order to ensure Europe’s competitiveness in this emerging field, the term CPS is often used as a synonym for systems in which computing interacts with the physical world as a networked embedded system. 9, 25
discipline a specialisation within a certain engineering area of knowledge such as me- chanical, electrical, control theory etc. 9
function a multi-disciplinary set of elements that constitutes a function in a system, such as the human-machine interface that displays data on a monitor screen for medical instruments. 9, 11
functional development project a term used in this thesis to refer to a interdisci- plinary project team. 10, 11, 13, 67, 70
mechatronic various attempts have taken place over the years to try to provide a con- crete definition of mechatronics [30]. There is not an uniform IEEE definition for it.
A generic definition of mechatronics, even though some would disagree on where the central theme of the integration of the core disciplines lies, involves the synergetic integration of electronics, mechanical engineering and information technology. Ex- amples of mechatronic products are: anti-lock brake system, robotic-assisted surgery, smart phone etc.. 9, 10, 26
multi-disciplinary product a product that involves different disciplines such as elec- trical, mechanical, software and control theory. 9, 70
product development project the term in this thesis refers to the development project of a product that is multi-disciplinary in a rather large organisation, with a wide diversity of people and expertise. The decision-making is done with account to the different departments involved. The multi-disciplinary product is therefore knowl- edge and technology intensive [28]. 9
project project Management Institute (world’s largest professional association) defines it as an unique and transient endeavour undertaken to create a unique result [32]. 32
T-shaped knowledge the vertical bar on the T represents the depth of related skills and expertise in a single field, whereas the horizontal bar is the ability to collaborate across disciplines with experts in other areas than ones own. 60, 68
Acronyms
CPM Critical Path Model. 35, 61
CPS cyber-physical systems. 25, 62, 68
DSM Design Structure Matrix. 16, 29, 64
ESS European Space Spallantion. 18, 41
OEM Original Equipment Manufactures. 30, 61
PCB printed circuit board. 28, 42
PDP product development projects. 9, 11, 27, 29, 42, 45, 68
SE systems engineering. 9, 11, 13, 37, 38, 45, 68
WBS Work Breakdown Structure. 35
1 Introduction to the Research Field
1.1 Background
To maintain the competitive edge, in the light of this century’s technological advance- ments and globalisation of markets [13], and adapt to the immense input of requirements, constraints and conventions, companies aspire to develop more complex and innovative systems [30] [29]. These complex systems, achieved by the synergetic integration of dif- ferent engineering disciplines such as mechanics, electronics and information technology, have been expressed, for a long time, by the term of mechatronics [14].
A multi-disciplinary product is usually decomposed and several product development projects are involved in developing functions or units1. Nonetheless, the complexity of product development does not arise solely from the technical complexity; it is also com- plex to manage [13]. Managing complex product development projects (PDP) is not an easy task to take on because the product is part of a bigger system and has technical de- pendencies to other parts and subsequently to other product development projects (PDP);
complex products are typically considered as a network of components that share inter- faces to function as whole [23]. This is a concern to organisations that develop complex mechatronic systems or cyber-physical systems due to the difficulty in identifying and understanding the technical dependencies. This stipulates the need for architects and experts, making it a concern for the project management, as it finds it challenging to fulfill the time, budget and quality restraints, when the product itself is under alternate ways of decomposition. Project management in organisations that develop complex multi- disciplinary products has become a core business process for most organisations [32].
Furthermore, each engineering discipline has different development processes, which also progress in different rates. The project management’s role is to coordinate and manage people [32], but since projects get bigger, involve more interrelations and expertise, it is actually overwhelming. There is a trend, especially in the academia, to start developing products in a functional way instead of the traditional disciplinary way, where different engineering disciplines are put into a team, an interdisciplinary team that work together in developing a function and hopefully the preceding challenges can be alleviated. There has been development methods that are functional such as the Y-chart, which have been
1968) when Ludwig von Bertalanffy first introduced the idea of regarding a system as a whole, with interacting parts [44]. In this thesis, these kind of functional projects will be referred to as functional development project.
1.2 Problematization
Multi-disciplinary products (mechatronic and cyber-physical) require a lot of profound analysis before development, making the concept and feasibility phase harder, longer and subject to excessive decision-making. In spite of the operational support in organisations, in form of methods and tools, companies still suffers from a certain amount of rework based on incorrect concept decisions [25]. Nevertheless, the decision-making has to be done in a timely manner and inclusive of all the disciplines from an early phase, which could be difficult as project management has to deal with challenges concerning communication;
the different disciplines use different semantics, have different yet strong opinions, and have a different approach to development tasks [28], see Figure 1.
Figure 1: Designers with different engineering backgrounds have different view of the same product. Figure taken from Malvius [28]
Moreover, the product requirements and boundaries can be blurry and specification or requirements can be non-existing. The requirements and specifications, when not fully defined, introduce problems with the division of responsibility and makes project mem- bers think that other projects are covering the problems, when in fact, there is nobody dealing with it. Problems with responsibility division causes integration challenges; when necessary tests are not done. The integration phase becomes very resource and time con- suming, when engineers misunderstand requirements, build according to old requirements, or lack specifications. The problem with developing disciplinary, which is what companies are used to do, is that the disciplinary units have to be integrated into multi-disciplinary
sub-systems, and due to some of the aforementioned challenges, most errors appear in that phase.
Instead of dividing the function into units, where they are developed disciplinary, the author proposes a thesis regarding the possibilities of working functionally, which means that teams work together in a functional development projects to develop architectural functions.
1.3 Research Aim and Objective
This study has a descriptive purpose and an abductive approach. Thus, this thesis does not set out to provide a profound description of the phenomena studied, which is the project management of complex product development but rather to emphasize on certain aspects of PDP. The aim of the thesis is investigate the challenges that Swedish companies face in order to provide a framework for PDP to work more functionally in projects when it seems appropriate, and to ameliorate the management of challenges specific for PDP.
The objective of this thesis is to account for how systems engineering (SE) can help with the challenges specific to complex PDP.
1.4 Research Question
Thus, to achieve the aim mentioned in the previous section in the context of complex PDP, the following research question has to be asked:
• ”How can project management deal with challenges specific to complex product development projects?”
1.5 Delimitations
This thesis includes companies that develop already market-established products, where new functions and features are added, creating the need for integrating new sub-systems to already existing and established design interfaces due to technical dependencies. The organisations that are investigated are Swedish industrial companies that are innovative and use the state-of-the-art in their field of interest, where the product being developed is highly integrated.
Therefore, the V-model is the development method that is investigated in depth in this thesis, and is compared to the agile methodology, which has inevitably taken more ground in recent years (these methods will be discussed in Section 3: Frame of Reference).
The complex products being investigated are mechatronic products and cyber-physical systems, exclusive of new trends such as Internet of things and smart infrastructures such as smart cities, smart health care and smart mobility etc. These systems are used in safety-critical environments, which means that the project management cannot be studied without taking into consideration safety and security standards and requirements that dictates how the work has to be done – this is, however, not included in this thesis.
Furthermore, the focus of this thesis is on the project management level and not on higher levels such as the programme management, organisational culture or any other area outside the project level even though they might have an impact on projects. The impact of external stakeholders such as marketing, maintenance, operational or disposal processes, and suppliers are not studied either in this thesis.
1.6 Thesis Motivation
Albeit, this thesis lacks an industrial stakeholder and there is, subsequently, not a clear identified problem to investigate. This thesis starts with investigating how Swedish com- panies develop complex products to identify challenges that the Swedish companies have in order to problematise further. This means as well that the analytical framework is not solely dependent on the frame of reference but also on the empirical findings.
1.7 Reader’s Guide and Overall Findings
This thesis is organised as follows:
• Section 1: Introduction to the Research Field describes the environments of complex PDP shortly and provides an understanding of the phenomenon studied on the topic of managing complex PDP.
• Section 2: Methodology describes thoroughly and motivates the methodology that encompasses all the stages from literature study to empirical data collection. It also includes an ethical discussion and reliability and validity section on the research methods.
• Section 3: Frame of Reference holds the literature study inclusive of basic con- cepts regarding CPS and mechatronics; related work about management and or-
ganisation of complex PDP through covering the state of the art in three scientific research areas: product development, project management and systems engineering.
• Section 4: Results corresponds to the aim of the thesis through providing the empirically found challenges that Swedish companies face. This section is divided into two parts: (1) The empirical background of the cases investigated regarding the unit of analysis and (2) findings from the investigated Swedish cases.
• Section 5: Discussion includes an analytical framework that describes how to manage PDP and gives recommendations for management of a functional develop- ment project developing a multi-disciplinary product and includes a discussion how systems engineering (SE) can be used in PDP. It also provides the reader of the contribution and sustainability dimension of this thesis.
• Section 6: Conclusion holds concluding sentences on the management of complex PDP, discusses how projects should be managed and led, and a note on the quality of the results is given.
• Section 7: Future Work presents the author’s thoughts on future work related to PDP and on SE implementation for Swedish companies.
2 Methodology
This Section is divided accordingly to the work methods used in this research: Method for gathering literature; method for designing the case study; method for collecting the empirical data; method for analysing the empirical data; and method for developing the analytical framework. In proximity to the methods ethics and limitations are discussed.
Figure 2 shows the iterative work process of this thesis work. The framework mentioned in Figure 2 is the analytical framework that is presented in Section 5: Discussion. All the steps shown in the figure will be discussed thoroughly in the following Sections.
Figure 2: The iterative work process of this thesis
2.1 Literature Study - Planning and Developing
The literature study presented in Section 3: Frame of Reference has been collected from the following main search engines for scientific articles: Google scholar, DiVA and KTHB.
The keyword used are complex product development, mechatronic product development,
technical dependency, product life cycle model, DSM, model-based languages and V-model (For definition of these words see Section 3: Frame of Reference). A list of the most impor- tant articles that this thesis bases its analyses on can be read in Appendix B: Literature List.
The stages of planning and development of the framework that Figure 2 shows is heavily based on the literature study. The abductive approach of this thesis begins with the literature study in order to understand complex PDP better and get in-depth knowledge of the phenomenon from the previous conducted research found in the search engines and from previous studied conducted in Machine Design Institute at KTH. The literature study is an important step for the thesis since the empirical findings are seen more of validation to the literature study. Therefore, it is not necessary to do excessive empirical date collection about aspects that can otherwise be read about. The empirical data collection has as a target to complement the theoretical study with real-context that is not emphasised in the academic journals. The theories and models found in the literature study and the complementary empirical findings are enough to generate the analytical framework in the last stage of the iterative process in Figure 3. Finally, the approach is called abductive because the empirical findings have led to building of new hypothesis and search for new theories.
Figure 3: The abductive approach highlighted
Figure 3 illustrates a circle that shows the abductive approach; the process starts with the general theoretical study and goes on to the more specific case studies (deductive reasoning), but it also shows the iteration process during the empirical data collection
period that leds to the building of hypothesis from the observations (inductive reasoning).
2.2 Design of Case Study
This Section describes the third step of the process and is conducted after the literature study. In this section the author explains how and why the case study method is used.
The research question is:
”How can project management deal with challenges specific to complex product devel- opment projects?”
Since the type of research question is how, then case studies, histories and experiments are suitable [9]. However, the thesis does not allow for a history method as the primary data that this kind of method relies on is not available for the author. In spite of the fact that history approach eliminates a vital source of evidence, which is obtained from direct observation of events and people being studied, the Swedish companies would be reluctant to have a researcher sneaking through documentation without supervision. Additionally, the author has no experience and should not be allowed to conduct experiments on humans.
Thereupon, the case study is the only option available. It is necessary for the reader to understand before going any further that this thesis work is not done for a specific company; hence, the results of this thesis work are generic and theory heavy.
A case study is suitable because the researcher has no control over the events and the focus is on contemporary phenomenon within a real-life context [9]. Using a real-life context contributes to generalising the theory, as Yin [9] points out when he underlines that a case study is used to generalize to theoretical propositions (analytical generalisation) and not to populations or universes (statistical generalisation). The starting point of a case study is that the focus is on one or few instance of a phenomenon instead of having a wide spectrum [38]. The phenomenon investigated has its focus, in this thesis, on the integration phase that is a rather small instance of a very wide research area.
Moreover, the case studies have been used in cases with an intention to advance the knowledge of systems engineering, and is practical because it advocate for a constructive approach and uses a non-reductionist understanding that is essential for dealing with complex systems [22]. It is important to keep in mind that when dealing with mechatronic
in a myriad of ways that change with context [43]. This research does not study or refer to advanced technology used nowadays but refers to the multi-disciplinary nature of the product that these components create when integrated together.
2.3 Research Methodology
The previous two sections gives insights on why the research method has a descriptive purpose and has an abductive approach. As has been mentioned earlier, the author begins with the literature study to understand the phenomenon better and then the case studies are done in order to gather more information and adapt or enhance the theory in afterhand.
This thesis case study contains multiple case studies with different companies, which offers understanding of real-life phenomenon and captures the aforementioned complexity.
The research method is about theory construction and building, which gives new holistic and in-depth understanding, explanation and interpretation that steam from the rich experiences the interviewees share. Moreover, questionnaires asked in a case study allow for provision of information on a particular point of interest [38]. The multiple case studies are done through using qualitative methods in order to get in-depth knowledge, but can also be seen as an attempt at triangulation in order to reduce bias. The case study is based on semi-structured interviews and are conducted at different Swedish companies:
Mycronic, European Space Spallantion (ESS), Ericsson and ˚AF.
In order to investigate how product development is managed in organisations data has to be gathered from the literature study and the real-context findings. The literature study identifies that the technical dependencies, the organisation structure and the culture of the organisations has to be investigated (see Section 3: Frame of Reference for detailed information). Therefore, a semi-structured interview is an excellent method to get both broad and deep knowledge about the subject [9] [38]. Two levels of collecting empirical findings are used in order to get an understanding of PDP: The first level consists of the pilot case study with semi-structured interviews with academic experts at KTH and industrial experts at Mycronic. The reason for choosing Mycronic for the first level is due to an early establishment of contact with the company. These early interviews, however, help conceptualise the problematization further. The second level is the case study that consists of multiple cases with the different Swedish companies that are described in detail in Section 2.4: Empirical Data Collection.
The semi-structured questions are formed from the conceptual framework (covered in Section 3: Frame of Reference) and from the early empirical findings (pilot case study),
but are, at the same time, designed to allow room for creative findings as opposed to structured interviews. The conceptual framework is found in Appendix A: Case Study and is designed to show analysis of the literature study. The questioneers used in the case study differs a little bit from each other depending on the unit of analysis but all have the same base, which is the conceptual framework, which are also found in Appendix A.
2.4 Empirical Data Collection
The people chosen for the interviews are experienced systems engineers or project managers according to the academic people the author consulted, with the motivation that the interviewees have a lot of experience and knowledge within the field of project management, product development or SE activities and processes. For detailed information about the interviewees, see Appendix A: Case Study.
The case study interviews have different focuses depending on the unit of analysis but can be summarized into looking at the role of project managers, systems engineers , integra- tion phase, product development, software development and organisational size. For exam- ple, looking at software product development, gives in-depth insights into the agile method- ology and the size of organisation for CPS gives valuable insight on team effort and compe- tence among other things. The unit of analysis in these cases can be categorised into the three levels that are mentioned in Section 3.2.1: Three Product Development Domains:
Organisation, process and product [5].
The empirical data is gathered with a unit of analysis that is determined beforehand and the open questions are used to understand the unit of analysis better and the closed questions are used to get facts clear. Table 1 on the next page shows a list of the par- ticipants and the unit of analysis, which is the focus of the interview. The names of the industrial participants are anonymous but their roles and job descriptions are given in detail in Appendix A: Case Study and in Section 4.1.1: Cases Investigated.
Company Profession Case focus Length Number of interviews
Mycronic Adjunct professor and R&D Man- ager
PD in concept phase 60 min 3
Mycronic Product Manager Project Management 70 min 1 Mycronic Senior Project
Manager
Project Management 60 min 1
Mycronic Chief Architect Prod. dev. 60 min 1
ESS Documentation
and Systems
Engineer
Org. size of CPS 90 min 1
˚AF Manager Elec- tronics Design
SE 60 min 1
Ericsson Software Devel- oper
Software Development 60 min 1
Table 1: List of conducted interviews
2.5 Cross-Case Analysis
The cross-case synthesis is used as an analysis technique for multiple case study as is advised by Yin [9]. The analysis is done in consideration of the backgrounds of the partic- ipants; the companies that they work in; and the nature of the product that is developed, which is either cyber-physical system or mechatronic systems. Since the outcome of the case study is an analytical generalisation, multiple case studies are enough to give the wanted contrast. In a cross-case analysis similarities and differences are studied and anal- ysed in order to identify the components that caused them [15]. Additionally, delimitation is used because analytical generalisation is the achieved outcome and if the scope and boundaries are not set the research does not reach the required depth or reasonable ana- lytical generalisation [15].
All interviews of the case study are recorded, transcribed and coded. The coding of the transcriptions consists of two levels: A pre-defined high-level and a content-driven low- level coding, which means that the high-level codes are predetermined before the empirical data collection and are formed from the theoretical background, while the low-level codes took form during the analysis process and correspond to a theme found throughout all the transcriptions, see Figure 24 in Section 8.3: Appendix C: List of Codes for more detail.
The reason for coding the transcriptions in this way is because it supports a general and
systematic analysis. After the analysis is done, a narrative presentation of the empirical findings is chosen due to the few number of participants and these are, in a natural order, a perfect number of characters for a story! It is advised, actually, by some academics to use a story-telling technique as it entails a better understanding of the world for human beings [41]. Moreover, it allows for a scientific reductionism [20].
2.6 Analytical Framework
The analysis of this thesis depends majorly on the theoretical background, whereas the empirical findings are used to capture trends of the industry through showing similarities or contradictions with the literature. In the discussion, the analytical framework is presented and supported by the analysis of the empirical findings. The semi-structured questions of the case studies are open-ended, which allows for creative finding [9] and the descriptive answers obtained from the past events of the participants allow for additional information that is used for developing the analytical framework. The empirical findings has caused new keywords to appear and that in turn leads to new literature to be searched for and added, which develops the analytical framework further.
2.7 Method to Verify the Analytical Framework
This section covers the last step of the iterative process.
In a sense, the V-model that is investigated is used as a development method for this thesis work; the framework is designed from the literature study and then developed further with the help of the rich empirical findings and then at last verified. However, the author has not had the time to test the framework in a real-context project and therefore the framework is theoretical. This thesis’ results are verified through the semi- structured interview with Chief Architect and R&D Manager in Mycronic, which are done partly in order to confirm or reject the hypothesis that emerge from the empirical findings.
Additionally, the author has had long interviews and short meetings with some industrial experts within SE and software development to discuss the analysis of her findings, and that is how this framework has been verified, see Table 2 on the next page for the two experts that the author shared her discussion with.
Name Profession Length Number of interviews Mats Vikstr¨om SE Expert 3 hours 2: physical and on telephone
Ulf Olsson Architect 1 hour 1
Table 2: List of experts interviewed during the analysis
2.8 Ethics
Regarding ethics, the author provides anonymity to all the participants of this thesis unless they state otherwise. It will make the validity process of the results harder to judge since the opponents or readers do not have access to the source of information. Nonetheless, according to the code of conduct, there will be a need to make sure that the dignity of the participants is kept intact [37]. As a matter of fact, this thesis involvement of social studies diminishes opinions that can be classed as absolute right or wrong. But opinions could be debatable; ergo, the author resolved on not publishing anything that might harm the participants in any way and consequently the participants’ names are anonymous.
Since this thesis lacks an industrial stakeholder, the author does not have to deal with ethical issues that perhaps other master thesis students have to deal with; the author does not need to consider if her results are not favourable to the participants [37]. Keeping the participants privacy, the author can present the results unhampered and without influence just on the account of pleasing a participant.
The author has absolutely to inform the participants of the purpose of the research in order to prevent any misleading or misunderstanding [41]; that is why the theoretical study preceded the empirical data collection. Consequently, the author could present a rather informative and communicative overview of the research area. Section 8: Appendix shows the interview guides that the participants read before the interview started.
2.9 Limitations set by the Research Method
Triangulation that the author uses is based on different sources of information that come from different companies, but there is a limitation of the triangulation of sources as the author did not look into documentations or records as the companies do not provide such sources of information. The empirical findings are limited to the academic and industrial semi-structured interviews. However, the companies are reluctant to share information regarding their products and the study questions are formulated in regard to the ethics of not pushing an interviewee to reveal such information. Besides that the industrial
supervisor was present at the meetings at Mycronic, with exception of the interview with the Senior Project manager, de facto that the interviews are recorded, interviewees become more conscience about the information they provide which limits the in-depths of the empirical findings.
2.10 Validity and Reliability
The case study is done in an iterative way because the analytical framework develops at the same time as the case study. In order to refrain from subjective judgments and increase the validity in the research design and data collection, triangulation is used;
multiple experts in different disciplines and organisational structure. Moreover, all the interviews are recorded, transcribed within a day and then coded systematically after that the transcriptions were first send to the interviewees to be reviewed. This is how the author tried to design the case study in the most rigorous way possible. According to some authors [22] this way allows for the capture of complexity and also enhance the quality of the data.
Nevertheless, there is one major concern to address, which is the fact that the compa- nies investigated are collaborating with KTH already. This means that the author cannot answer if the results obtained from the case study is due to some kind of correlation or cau- sation. There is a possibility that the findings of this research could be different if the case studies were conducted on other Swedish or foreign companies that do not share the same technical or philosophical way of thinking. However, the multiple case studies develop dif- ferent kinds of products, which can be seen as an attempt to alleviate philosophy-biased results.
Since the social science is highly dependent of human begins that are effected by a complex stimulus, the human face, and external events, such as time and place, the results are most likely not similar if conducted again [9]. The author’s best chance of emancipation is through giving full account of theories and ideas, recording, transcripting and coding of the interviews, keeping detailed case study analysis and providing all of them if asked for (for more information see Appendix A: Case Study). Lastly, the assurance of the congruence between the literature and the empirical findings stands for the reliability and validation of this research.
3 Frame of Reference
This section includes a description of complex products and the relevant state of the art within three scientific research fields, which are: Project management, complex product development and systems engineering. The reason for the fragmentation is due to the fact that these aforementioned scientific fields have evolved, in the literature, unilaterally but are unanimously affiliated in the state of practice2. That is why the author has to include, but at the same time, fragment the three scientific fields.
3.1 Complex Systems
The complex systems that this thesis focuses on is mechatronic products and cyber physical systems, which are described below:
3.1.1 Cyber-Physical Systems
The concept Cyber comes from the philosophical trans-disciplinary approach for control- ling systems or things called cybernetics, and physical refers to all systems that have physical elements. Consequently, a cyber-physical system is a combination of physical and software components that intertwine together even though these two components are developed separately [43]. It is the recent innovations in technological fields like embedded systems and computing, communication, sensors and actuators, informatics and control that have enabled the implementation of complex systems that are able to control and coordinated physical and organizational processes on a local and a global scale [45]. These systems are usually composed by a set of networked agents, including: sensors, actua- tors, control processing units, and communication devices, see Figure 4 on the next page.
The cyber-physical systems (CPS) are found in five key areas of importance in Europe, which are within the smart transportation systems; the smart health-care system, smart production, smart energy and smart cities [43] [45].
The merge of the physical and the software worlds is not easy, the idea of making different components interact and network is challenging because the decisions that are made in one world, during whichever stage in the life cycle, have to be communicated to the other world in a timely manner so that it can be reflected upon and adapted to [43].
Figure 4: General architecture of a CPS, where the computing and communication ca- pabilities are integrated with the monitoring and control entities in the physical world.
Figure taken Cardenas et al. [24]
aspects [45]. The educational challenge that organisations developing multi-disciplinary are affected by is the lack of cross-functional knowledge. This lack of provision can be counteracted by preparing education and training programs for the transfer of evolving knowledge, balancing theory and practice [45]. The economical challenges are concerned with the support for the establishment of new business models by anticipating a shift from products to services, whereas the technical challenges are those concerned with the need for engineering methods and technologies that can be used in the required level of complexity in the form of interoperable platforms, methods and tools [45].
Moreover, the cyber-physical systems will transform how we interact with the physical world around us; this can be witnessed with the increased amount of products that are connected to the same network: Be it the Internet, a server or a cloud. Albeit this connectivity enables products to receive updates and send feedback or save data in a form of continuous information flow, the systems have to be robust and reliable [24]. In recent years, CPS have been under the threat of cyber attacks [24]. Besides security and safety, the complexity drivers of CPS can be summarised into: self-, live- and cross-dimension.
CPS have to be self-operating, get live-updates and work cross-domains [45]. For more information about the dimensions, see Section 8.2 Appendix B: Literature List.
3.1.2 Mechatronic Products
Mechatronics is the discipline that emerged from the synergistic integration of the fields of mechanics, electronics, control theory and computer science within the process of product
design and manufacturing that is characterised with complex decision-making [30] [11] [3].
The design of a mechatronic system differs from the design of a product coined by mainly one engineering discipline because mechatronic systems3 are complex in nature due to the great number of connected elements, known as cross-functional [14]
This cross-functionality creates new functions such as the anti-lock system, active suspension and brake-by-wire in the automotive industry, which are only possible from the synergetic effect of merging disciplines. The difference between CPS and Mechatronics is the scale, while mechatronics systems are more electro-mechanical oriented systems, the CPS target other large-scaled physical and organisational processes with distributed control and automation, which interact together and create system of systems [45].
Besides the complexity of the products, the product development environment is very complicated. The product gets divided and the sub-systems go through different stages in different rates and with different time frames. There is a need to have a clear understanding of the work environment in order to succeed in developing complex products.
3.2 Complex Product Development
This section will provide the reader with the most relevant information about product de- velopment. The previous section provided an understanding of the systems but this section provides information about how to develop them, decompose them and what constitutes the bases for decision-making.
3.2.1 Three Product Development Domains
Eppinger and Salminen [5] have identified three dimensions that complex product devel- opment projects (PDP) consists of: the organizational complexity, the process complexity and the product complexity . The general approach when developing complex products is to decompose the product into systems, and if the systems are still too complex, decom- pose these into sub-systems and then into components [5] [2]. A full development process is decomposed into phases or sub-processes, and these in turn may be further decomposed into tasks, activities, and work units. A process tells how to go from point A to B and
3.2.2 Life Cycle Stages
There are typically four fundamental stages in any product development project: Concept, development, execution and retirement (ISO/IEC/IEEE 15288:2015). Figure 5 shows a generic life cycle model that all products go through:
Figure 5: Generic life cycle model. Adapted from (ISO/IEC/IEEE 15288) and (ISO/IEC 24748) [44]
Each stage contains activities to achieve the goals of respective stage. For each project, it is essential to define requirements and publish the terms and related definitions used to minimize confusion and to indicate when to transit from one stage to the next, which is done usually through the use of milestones [49]. As products evolve into a very complex and heterogeneous nature, the life cycle stages vary and different R&D departments have different set-ups [44].
Although these categories differ in detail, they all have a sequential format that em- phasizes the core activities and it is important to consider that many of the activities throughout the life cycle are iterated [49]. The method or process does not have to be sequential as the model is. In fact, the product is decomposed into sub-systems and then into components, which suits a specific operating principle or disciplinary procedure and this introduces a time sequence, which has to be followed in order to develop the sub- system, but which might deviate from the logical sequence that a life cycle model shows [27].
3.2.3 Modular and Integrative Systems
There are two types of systems: modular and integrative. The modular systems have well defined interface and is shared with only a few systems, e.g. mounting of electrical printed circuit board (PCB) on a robotic arm. The integrative systems are those whose interfaces may be more complex and shared across the product, e.g embedded systems.
The development of complex products usually involves both modular and integrative sys- tems. There are significant differences between the design processes of these two systems [23]. The tools used for integrative systems are more complicated, since the architecture of integrative systems spread over different disciplines.
3.2.4 Design Structure Matrix (DSM)
In general for product development, and in particular for multi-disciplinary products, Pimmler and Eppinger [2] advocate for the use of decomposition. The technique is useful for developing an understanding of the system engineering needs, which arise due to the complexity of the interactions between components of a design [2]. In the development of any complex engineered system or product, the function of the device has to be de- composed into multiple sub-functions so that teams can research solutions for each of the smaller pieces on their own. Albeit the product architecture is an extremely influential decision, which must be made during the system-level design phases, the architecture de- fines the sub-systems upon which the team will work for the bulk of the development effort [2]. The interactions between the sub-systems have to be considered notwithstand- ing that there are potentially many insights into the structure of a product development problem. There are alternate perspectives of the problem: (1) Decomposition and cluster- ing of components into architectural functions based on individual interaction types and (2) identifying system engineering needs by developing product architectural and team chunks based on the design challenges involved; therefore, the interactions should only be considered after the architecture is chosen [2].
While many project management tools (for example Gantt) allow modeling of sequen- tial and parallel process, they fail to address interdependency (feedback and iteration) that is common in complex PDP [18]. To address this problem Design Structure Matrix (DSM) has evolved; the DSM uses the first alternative by considering the interactions and represents the relationship of complex tasks in order to determine a sensible sequence or groupings for the tasks or teams. The DSM therefore allows for the capturing of informa- tion flow instead of workflow [18] [13]. Some are adherent to the second alternative, such as Danilovic and Browning who believe that one way of capturing the complexity of prod- uct development is through presenting and analysing the design structures or architecture [21]. Moreover, one of the challenges with using DSM, is that it requires knowledge of all the activities, predefined requirements and the flow of information and does not syn- chronize decisions across domains [21]. The work required to develop PDP is complex due to the number of activities, people, teams, and organizations involved and their relation- ships. These areas are interwoven, creating a number of complexities and uncertainties
3.2.5 Technical Dependencies
The development of mechatronic products involves multiple stakeholders which have dif- ferent viewpoints and use different concepts, models and tools to deal with their concerns of interest. Thereupon, there is a need to emphasis the relations between viewpoints in order to deal with evolving scope and requirements on mechatronic products [39]. View- point contracts are used to define the vocabulary, assumptions and constraints required for ensuring smooth communication between stakeholders and team members (people level).
However, dependency models capture relations between product properties belonging to different viewpoints, and how such dependencies relate to predictions and decisions (model level) [39] [35]. Dependency models aims to identify and solve dependencies across differ- ent domains during the design process of a mechatronic system at the model level [35].
What dependency models do is that as the modelers perform the design iterations in Simulink 4R and/or in Solid Edge R, the updates on cross-domain dependencies will be available through SysML model, containing the complete system view [35].
Additionally, the contracts are used as a mean to meet the challenges in the design of CPS; one of the challenges that triggers the usage of contracts is the increasing complexity of the development environment of CPS, which is characterized by distributed Original Equipment Manufactures (OEM)/ suppliers [40]. Interfaces can also be seen as a contract between the component and its environment [39]. The contract specifies the assumptions that the component makes on the behavior of the environment, and holds constraints that makes sure that the component and the environment meet their respective responsibilities [40].
3.2.6 Virtual Environments
There are a lot of examples for situations where misunderstanding occurs and that visual illustration of the information enhances the understanding of the receiver or audience. One example, is when the space shuttle Challenger exploded in 1986, where seven astronauts died. The night before the launch, engineers prepared 13 charts with evidence to convince NASA managers to cancel the launch due to O-rings5 that could cause huge problems because of the cold weather. A combination of cultural differences, bureaucracy and possibly bad visual argumentation hindered the engineers from presenting and visualising the problem in a clear and convincing way and so failing in convincing the managers to
4Simulink is developed by MathWorks as a graphical programming environment for modeling
5O-rings are used to seal the interface between two parts in a joint
stop the launch [52].
Adamsson [19] mentions that a successful mechatronic design setting is largely depen- dent on: efficient communication, collaboration and integration of the involved disciplines.
However, to overcome managerial difficulties, virtual environment can be used as an over- all architecture during the whole product life cycle since it can be used as a basis for semantics6, information management, anomaly treatment and collaboration enhancement [42].
3.2.7 Model-based Language
Many problems in systems and safety engineering are known to originate from misalign- ment of assumption and concepts (implicit interface) among the multiple stakeholders within an organisation [39]. A proper management of the relationship between viewpoints advances the development time and fulfils the requirements (technical and economical).
Additionally, Model-based language can be used by various stakeholders and has different abstraction levels such as sysML R that is a graphical modeling language developed by the Object Management Group, the International Council on Systems Engineering (IN- COSE), and AP233 (a standard data exchange format) [44]. There are general-purpose and domain-specific model-based languages. However, to address the viewpoint inter- relations it is better to use multiple domain-specific model-based languages instead of extending the general purpose modeling language, which adds accidental complexity7 to the intrinsic complexity of the underlying system [39].
Adamsson realises that there is a need to treat the engineering disciplines and the man- agerial/ organisational interface between the disciplines separately [19]. The difficulties in global collaborated product development do not arise simply from the technical complex- ity but also from the managerial complexity since interactions between various engineering disciplines have to be managed, which can be allocated in different geographical locations.
The managerial complexity imposes additional challenges on the development process in a time-based competition [13].
3.3 Project Management
The following Sections contain the state of the art of some project management techniques and literature that cover the aspects needed for managing and leading the development of complex products.
Maylor affirms that the project management is the integration point of knowledge and theory of other disciplines and refers to that point to where the “rubber hits the road”
[7]. What he means by that is that there are many stakeholders in a project such as marketing, human resource management, operations and finance, which makes project management a strategic weapon [8]. The project management can be seen as a tool for delivering the operation and business goals [33], the business strategy is long-termed and therefore has to be decomposed into concrete action plans that can control the everyday work and since projects are work-oriented with focus on results, it becomes a perfect tool.
Project management can be seen as a process of sequential activities that has as objective to produce in pursuance of satisfying a need [32].
The project has a start and an end that goes through four generic stages: Conceptual- isation, Planning, Execution and Termination [46]. The typical project model for product development is as Figure 6 shows [33]: The stages in the figure forms a project as an ad hoc endeavour with clear life cycle; making the project a temporary organisation that is disbanded when the life cycle reaches termination stage [33].
Figure 6: Generic project life cycle stages and project model for product development.
Figure adapted from [33]
Maylor [32] defines four phases for a project, called the 4-D model: Define it, Design it, Do it, Develop it. This process is iterative as can be seen in Figure 7 in the next page.
Figure 7: Project phases according to Maylor [32]
Maylor explains what should be involved in each phase [32]:
• Define phase: This is the time when it is determined what the project is about, its reasons for existence and the intentions that it intends to progress. It is a time to explore the possibilities, find alternatives to the problems presented.
• Design phase: In this phase models are constructed to show how the needs will be developed, evaluate these to determine the optimum process for the task and minimise risk.
• Do or deliver phase: In this phase the project is carried out in line with the models or plans generated above.
• Develop phase: Improvement of products and processes in the light of the experience gained.
The best way to reduce or minimize risks is to perform better planning and most
have the responsibility to define how the tasks will be done and stands for the deliverables.
Kerzner seems to refer to line managers when he talks about the functional managers but in nowadays companies a line manager is seldom responsible in projects since it becomes overwhelming. He altogether identifies a need for a functional manager in a project that helps the project manager [6].
Putting this into complex product development environment, project managers have to make sure that there is a connection between the purpose of project and business strategy [33]. For instance, it is not sufficient to deliver a brilliant made technology solution without training the operators or having widespread media coverage [32]. On top of that, the output of the project in complex product development context is part of another systems and has to be integrated which puts focus on scope management [32].
The increasingly complex and technical products such as cars nowadays that have more computer power than the Apollo 11 that set a man on the moon, make it challenging to produce efficiently and to maintain control of the entire process [46].
3.3.1 Project Management Phases
The scope statement reflects a project team’s best effect at creating the documentation and approval of all the important project parameters prior to proceeding to execution stage [46]. The most used and known tool is the Work Breakdown Structure (WBS) [33], and it helps with establishing project goals criteria and developing the project plan by showing a hierarchical structure and reflects the careful and detailed work in a document [46]. However, it does not take into consideration uncertainties that for example software development have: Brooks is most known for Brook’s complexity where he compares the development of software to werewolves because they share the same nature of turning unexpectedly from a familiar state into something malicious. The software has therefore an essential and an accidental complexity [1]. Brooks concludes in his book that the essential complexity of software is not going to disappear anytime soon and so in planning any software activity, it is necessary to allow for iterations between clients and development teams as part of the system definition [1]. However, the accidental complexity can be reduced by avoiding awkward programming languages and lack of machine time but the essential complexity is harder to overcome and according to Brooks can be managed by spending effort to find and develop great designers upon whom the technical excellence of the products will ultimately depend [1].
Time management is another important phase for the project management: The Gantt
chart, which was created in 1917, is still a useful tool for establishing time-phased network of activities [46]. This tool is used to assess the difference between planned and actual performance. Gantt charts allow for continuous updating and project control that is essential in environments of narrow product launch windows, product upgrade and fierce competition [46]. Additionally, CPM is a technique used in time management phase to show the amount of scheduling flexibility by assuming that the time of activities is known and deterministic [46]. The most important thing is the critical path that shows the path with the longest duration in the project. The CPM is essential for projects that are made up of a number of individual activities that depend on other activities to finish before they can start, making a project a complex web of activities [16]. But it fails to cover the reasons why the planning is carried out in a specific way and it encourages one-step approach to planning [7]. Maylor argues that modern visual tools show high quality of coloured charts that gain more credibility for that reason and people become reluctant to challenge the information presented [7].
3.3.2 Agile Methods
Agile project management differs from traditional project management through recogniz- ing that the old approach of executing plans does not take into consideration uncertainties and that customer needs change [46]. Agile methodology believes it is dangerous to create a plan and disengage from the customer/project owner during the course of development;
it makes little sense to create a detailed product WBS if the project scope is inevitably going to change [46].
In the mid-1990s, the agile methodology emerged as a reaction to the then estab- lished methods such as the V-model, the Waterfall model and various implementations of stage-gate models that they rely on heavy documentation, formal processes for control and verification, planning, etc. [50]. However, requirements changes and technical de- pendability characteristics are best implemented with plan-driven methods, that is to say a systematic way rather than a rapid way is suitable. Organisations must find a balance between agile and plan-driven methods to address these disparate needs [10].
At the same time, agile methods are iterative development processes that are most
mental development, prototyping and quick feedback rather than extensive planning and documentation [34] [10]. Scrum methods organises the product development team with around ten members, one of which is selected or elected as scrum master. The main role of a scrum master is to act as an interface between the team and the external world, and to keep order and ensure focus but also it is requires from the scrum master to handle contact with the product owner. The Product Owner is a representative of the product to be developed, which can be an external customer or somebody with an interest of the final product [34].
Using additive methods such as 3D-printers and extreme prototyping help the devel- opment to become more interactive but still, there are many obstacles. It is difficult to break down the hardware development into iterations and the life cycle is different than software development in terms of maintenance and lifespan [36]. However, the term agile has becomes strongly associated with flexibility, where people from industries want to tear down company walls, pair technical and business people and involve key customers from key markets in order to be flexible [36]. Another reason for wanting to be flexible is that instead of committing to a plan that rapid change risks to make obsolete or is very expensive to keep up to date, agile, as a methodology, focuses on getting the pieces of the products (the features) that deliver functional value to customers [46].
3.3.3 Project Success Criteria
The traditional project triangle with time, budget and performance at its corners is used to measure the project success. However, according to a study most project manager respondents ranked quality before budget and schedule when asked about the project tri- angle [12] and that is in accord with Shenhar et al. [8], where the authors state that the success of the project is the resultant product. Additionally, they contribute in their research with a framework for success dimensions, which are: project efficiency; impact on customer; direct business and organizational success; and preparation for the future [8]. Furthermore, they consider the time frame and technology maturity, where little time allows for project efficiency but as more time is given, the impact on customer, business success and preparation for the future can consequentially be dealt with. Maylor [32] like- wise states that the literature on traditional approach to project management is striking because it is geared towards assuring conformance to budget, scope and time constraints and leave out higher considerations such as the need for excellence (optimization), contin- uous improvement and customer delight, which is the fourth criterion that has, in recent
