Systems Engineering at Damen Shipyards Applying systems engineering in the concept development phase of standard vessels

Master’s thesis - I.H.S. Lely 4107640

TU Delft: J. Pruyn, PhD Damen Shipyards: K. Silvius, MSc

Report number: SDPO.18.042.m.

Marine Technology

November 23, 2018

PREFACE

This master’s thesis is conducted as a requirement for the Maritime Masters course ’MT54015 - MSc Thesis’, which constitutes part of the Marine Technology masters program at Delft University of Technology. The fol- lowed master track is the Design, Production and Operation track, with the specialisation in Ship Production (MT-MS-DPO-SP-15). This project responds to the following research question:

In what way can systems engineering improve the effectiveness of the concept development phase of High Speed Craft standard projects?

Trying to change an existing company culture, which is based on years and years of experience, is a big chal- lenge. My goal is to convince Damen Shipyards that applying systems engineering in the concept development phase ultimately is to their own benefit and I sincerely hope that they will have the courage to implement the proposed framework.

Thank you Damen Shipyards for giving me the opportunity to conduct this research. Thank you Kasper Silvius, Maarten Deul from Damen Shipyards and thank you Jeroen Pruyn and Robert Hekkenberg from the Technical University of Delft for your help and critical views throughout the research. Thank you family and friends for the large amounts of support you all showed, in particular to Sarah Rose for supporting me every day and hav- ing the most loyal aunt in the world; Marianne Wolfhagen. Marianne, without your help I couldn’t have done this and I owe you for ever.

Enjoy reading this report!

Irith Lely

Master’s Thesis i Irith Lely

SUMMARY

The motive for this master’s thesis comes from reoccurring problems at Damen Shipyards with external and internal alignments regarding the product definition, hand-over between sales and project management and quality control during the concept development and execution phases of (standard) vessels. Damen Ship- yards is a Dutch company, founded in 1927 at Hardinxveld-Giessendam. They build, repair and refit vessels off all types, all over the world.

The Design & Proposal department (D & P) of the Commercial New Build Division (CNBD) carries out de- sign processes for one-off and standard projects. The demands of the client are captured within the contract specifications and the general arrangement plan, created by D & P by applying the design spiral. D & P also produce the IDC (Integral Direct Cost), which contains amongst other things the estimation of required hours and costs. VTC documents (Variation To Contract) are used to adapt the contract. Contract specifications of standard vessels can be created in a couple of hours by one single D & P engineer.

In accordance with Damen Shipyards, the research focuses on the concept development phase of standard projects within the business unit High Speed Craft (HSC) with the aim to improve the effectiveness of the ship design process. The problems encountered during the concept development phase and the execution phase regarding controllability of the design process, and quality and effectiveness of the vessel, are most likely to be solved by changing the approach of the concept development phase.

Based on the problem definition, the impact of the problems and the promising potential results of systems engineering, this thesis provides an answer to the following research question:

In what way can systems engineering improve the effectiveness of the concept development phase of High Speed Craft standard projects?

The field research is conducted to map the current concept development phase at HSC, through numerous interviews with engineers and managers of various disciplines from Damen Shipyards Gorinchem, plus inter- views with external experts in the field of the shipbuilding industry. The theoretical background is based on relevant books, articles, papers and studies and experiences with implementation of systems engineering in other projects of Damen Shipyards. A comparison of five life cycle models (V, DoD, Waterfall, INCOSE-V and Kossiakoff) and the study of various papers leads to a proposed combination of the V-model, the Kossiakoff- model and the SBS structure of Moredo & Krikke, to implement systems engineering.

Based on the outcome of the field research and the theoretical background, it is concluded that by perform- ing the proposed framework, the effectiveness of the concept development phase of HSC standard projects is improved. The results include a tailored framework and subsequent guideline, to allow Damen Shipyards to introduce systems engineering in the concept development phase of High Speed Craft projects.

Master’s Thesis iii Irith Lely

CONTENTS

Preface i Summary iii List of Figures 3 List of Tables 5 1 Introduction 7 1.1 Damen Shipyards...... 7 1.2 Shipbuilding Process...... 9 1.3 Problem Definition...... 13 1.4 Impact of the Problem...... 15 1.5 Summary, Scope, Aim & Research Question...... 17 2 Literature & Research 19 2.1 General Design Approaches...... 19 2.1.1 Complexity...... 19 2.1.2 Different design spirals...... 20 2.1.3 Spiral Improvements...... 22 2.1.4 Systems Engineering...... 24 2.2 Systems Engineering & Benefits...... 26 2.3 Effectiveness in Shipbuilding Processes...... 29 2.4 Current Concept Development...... 31 2.5 Differences Current Situation and Systems Engineering...... 36 2.6 Systems Engineering Framework...... 38 2.6.1 Life Cycle Models...... 38 2.6.2 Proposed Framework...... 42 2.6.3 Transition of procedures...... 44 2.7 Costs...... 47 3 Conclusions 55 4 Discussion 57 5 Recommendations 59 APPENDICES I A Different FCS Vessels I B CNBD Organisational Chart III C Examples Problems V D Non-Quality Costs IX E Paper J. de Vries XIII F SE at CNBD XV GV&V XVII H Incose Handbook XIX I Moredo/krikke XXI J List of SE standards XXIII K Design Criteria Small FCS XXV L Steps Kossiakoff Life Cycle Model XXXV

Master’s Thesis 1 Irith Lely M Acronyms & Abbreviations XXXIX N Bibliography XLI

Master’s Thesis 2 Irith Lely LISTOF FIGURES

1.1 Vessel Construction Options - DTC [Source: Damen Shipyards]...... 8 1.2 General Shipbuilding Process [Sources: Damen Shiphards; Irith Lely]...... 9 1.3 Vessel Contract [Source: Damen Shipyards]...... 9 1.4 IDC [Source: Damen Shipyards]...... 10 1.5 Design Spiral [Source: Evans, 1959]...... 10 1.6 Design Process - New standard Designs [Source: Irith Lely]...... 11 1.7 DTC - Design Gap [Source: Damen Shiphards]...... 12

2.1 Design Spiral Evans [Source: Evans, 1959]...... 20 2.2 Design Spirals Watson [Source: Watson, 1998]...... 21 2.3 Design Spiral Rawson & Tupper [Source: Rawson & Tupper, 2001]...... 21 2.4 Design Spiral Papanikolaou [Sources: Papanikolaou, 2014]...... 22 2.5 Concurrent (Parallel and Integrated) Product Development [Source: Bennett & Lamb, 1996].. 23 2.6 Allocation of Functional Requirements to Systems Breakdown [Source: Leidraadse, n.d.].... 24 2.7 Tailoring requires balance between risk and process [Source: Haskins, 2006]...... 27 2.8 Theoretical Effectiveness [Source: Veeke et al., 2008]...... 29 2.9 Actual Productivity [Source: Veeke et al., 2008]...... 29 2.10 Max. Theoretical and Standard Productivity [Source: Irith Lely, based on Veeke et al., 2008]... 29 2.11 Efficiency [Source: Veeke et al., 2008)...... 30 2.12 Actual Effectiveness [Source: Veeke et al. (2008)]...... 30 2.13 System Codes Damen [Source: Damen Shipyards]...... 31 2.14 Example System Codes Damen - 000 capacities [Source: Damen Shipyards]...... 32 2.15 Example System Codes Damen - 000 Sailing Profile [Source: Damen Shipyards]...... 32 2.16 Example System Codes Damen - 200 [Source: Damen Shipyards]...... 32 2.17 Example System Codes Damen - Hull shape [Source: Damen Shipyards]...... 33 2.18 Current Results & Sacrifices [Source: Irith Lely]...... 34 2.19 Info from Figures 2.14 through 2.17 translated into Systems Engineering [Source: Irith Lely]... 36 2.20 General Systems Engineering - Results & Sacrifices [Source: Irith Lely]...... 37 2.21 V-model - Dutch Civil Handbook [Source: Irith Lely, based on Leidraadse, n.d.]...... 38 2.22 DoD Process & Model [Source: Calvano et al., 2009]...... 39 2.23 Waterfall Model [Source: Kossiakoff et al., 2011]...... 39 2.24 INCOSE: V-model [Source: Haskins, 2006]...... 40 2.25 SE Life Cycle [Source: Kossiakoff et al., 2011]...... 40 2.26 SE Life Cycle Explanation [Source: Kossiakoff et al., 2011]...... 41 2.27 Proposed Framework [Source: Irith Lely, based on Kossiakoffet al., 2011; Leidraadse, n.d.].... 42 2.28 Generic setup of systems engineering [Source: Irith Lely]...... 43 2.29 Example of allocation of sections within Systems Engineering [Source: Irith Lely]...... 43 2.30 SE Process - New Concept Development Phase [Source: Irith Lely]...... 44 2.31 Guideline - Transition of Procedures [Source: Irith Lely]...... 45 2.32 SE Standards HSC - Result & Sacrifices [Source: Irith Lely]...... 46 2.33 Generic Operational Objectives - FCS [Source: Irith Lely, based on Kossiakoff et al., 2011].... 47 2.34 Function category versus functional media [Source: Kossiakoff et al., 2011]...... 48 2.35 System Functional Elements [Source: Kossiakoff et al. (2011)]...... 49 2.36 DOORS interface - Car Example [Source: DOORS, n.d.]...... 51 2.37 System Breakdown Structure [Source: Moredo & Krikke, 2010]...... 51 2.38 Two System Breakdown Structures...... 52 2.39 MOE, MOP versus Objectives and System Requirements [Source: Irith Lely, based on Calvano et al., 2009]...... 52 2.40 Cost Systems Engineering High Speed Craft - Results & Sacrifices [Source: Irith Lely]...... 53

3.1 Proposed Framework [Source: Irith Lely, based on Kossiakoffet al., 2011; Leidraadse, n.d.].... 55 3.2 Conclusion - Results & Sacrifices [Source: Irith Lely]...... 56

Master’s Thesis 3 Irith Lely A.1 Family Vessel Types - Fast Crew Supplier [Source: Damen Shiphards]...... I

B.1 Organisational Chart CNBD [Source: Damen Shipyards]...... III

D.1 Percentages Warranty Costs per Business Unit [Irith Lely based on Damen Shipyards]...... X D.2 Visible Warranty Costs Versus Non-Visible Non-Quality Costs [source: Damen Shipyards]....XI

F.1 Requirements Management Links [Source: Vries, 2015; DOORS, n.d.]...... XV

G.1 V & V goals [Source: Damen Shipyards]...... XVII G.2 V & V - Why [Source: Damen Shipyards]...... XVII G.3 V & V - How [Source: Damen Shipyards]...... XVIII G.4 V & V - What [Source: Damen Shiphards]...... XVIII

H.1 System life cycle processes overview per ISO/IEC 15288 [Source: ISO, 2002]...... XIX H.2 Tailoring Process Context Diagram [Source: Haskins, 2006]...... XX H.3 Tailoring Process Context Diagram [Source: Haskins, 2006]...... XX

I.1 FBS & SBS [Source: Moredo & Krikke, 2010]...... XXII

K.1 Design criteria FCS - first part page 1 [Source: Damen Shipyards]...... XXV K.2 Design criteria FCS - second part page 1 [Source: Damen Shipyards]...... XXVI K.3 Design criteria FCS - first part page 2 [Source: Damen Shipyards]...... XXVII K.4 Design criteria FCS - second part page 2 [Source: Damen Shipyards]...... XXVIII

L.1 Concept Development Phases of a System Life Cycle [Source: Kossiakoff et al., 2011]...... XXXV L.2 Systems Breakdown [Source: Kossiakoff et al., 2011]...... XXXV L.3 Needs Analysis [Source: Kossiakoff et al., 2011]...... XXXVI L.4 Concept Exploration [Source: Kossiakoff et al., 2011]...... XXXVI L.5 Concept Definition [Source: Kossiakoff et al., 2011]...... XXXVII

Master’s Thesis 4 Irith Lely LISTOF TABLES

2.1 Comparison of Systems Engineering Life Cycle Models [Source: Irith Lely]...... 41

D.1 Cost Estimate Example - Per Activity Type [Source: Irith Lely]...... IX

Master’s Thesis 5 Irith Lely

1 INTRODUCTION

The motive for this master’s thesis comes from reoccurring problems at Damen Shipyards with external and internal alignments, hand-over and quality control during the concept development and execution phases of (standard) vessels. Damen Shipyards is a Dutch shipbuilding company, founded in 1927 at Hardinxveld- Giessendam. They build, repair and refit vessels off all types, all over the world.

This chapter starts by further introducing Damen Shipyards (Section 1.1), followed by an explanation of their shipbuilding process (Section 1.2), definition of the problems (Section 1.3), their impacts (Section 1.4) and a summary of this chapter, resulting in the scope, research question and sub-questions of this master’s thesis (Section 1.5).

1.1. DAMEN SHIPYARDS Damen Shipyards (further referred to as ’Damen’) is a group of companies that sells, builds, repairs and con- verts vessels all over the world (yearly 160 vessels sold, built at 35 yards). One of these companies is the Com- merical New Build Division, which designs and builds all types of vessels. The major companies within the are:

• Yachting (Amels): super yachts • Ship repair & conversion (SR&C): all types of vessels • Damen Schelde Naval Shipbuilding (DSNS): complex naval vessels • Commercial New Build Division (CNBD): all types of vessels, including patrol vessels (super yachts ex- cluded)

Damen recognises two types of projects:

• One-offs (Engineering To Order - ETO) • Standards

Damen is known for their strategy to build semi-prefabricated vessels in standard projects. Most standard ships have their hulls fabricated before being sold, which is unique in the shipbuilding industry. Thus, lead time from ordering to delivery is diminished significantly, without losing the so-called ’Damen quality’. Not all types of vessels can be built in standard projects. Size, complexity and predominantly customer demands decide which vessel types are built repetitively with a standard design package and which types are one-off projects. When a one-off design is successful, it may become a standard design. Most standards are devel- oped by Damen with the clear intention to design a basic platform, to which options and particularities can be added in conformity with the client’s specific wishes.

In general, most new vessel types are based on existing vessels, with slightly different characteristics (e.g. big- ger dimensions, higher top speed, different sailing characteristics, more deck-space or capacity). In this way, families of vessel types are created. AppendixA shows an example of the Fast Crew Supplier (FCS) family. Damen has developed vessel families such as the Standard Tug, Standard Patrol Vessel and many more; the complete Damen product portfolio can be found online (Damen, n.d.).

Master’s Thesis 7 Irith Lely The scope of this thesis is Damen’sCommercial New Build Division (CNBD). CNBD consists of various business units (BUs, see AppendixB for an organisational chart), amongst which:

• Workboats: tugs and vessels • HSC (High Speed Craft): fast vessels such as Fast Crew Suppliers (FCS), interceptor and fast • O & T (Offshore and Transport): big ferries and offshore patrol vessels (OPVs) • C & O XL (Crew & Offshore XL): big passenger ferries • DTC (Damen Technical Cooperation): all vessel types • Services: the ’after-sale’ activities of all vessel types

All business units have allocated Damen yards, except for Damen Technical Cooperation (DTC) as they work with subcontracted DTC yards. DTC builds vessels of all business units, however, they do this on yards not owned by Damen, often on remote locations (e.g. a lake further inland), which cannot easily be reached by water. Some clients wish to build a ship locally, for example due to political requirements such as a guaran- tee of local content. DTC contracts local yards for the duration of the project, which thus become DTC yards. Client, DTC and DTC yard agree on the various responsibilities of all parts of the project.

DTC offers clients direct access to the entire portfolio of Damen vessels with multiple construction options, as shown in Figure 1.1: combinations of design and licenses, material packages, building assistance and building on-site/turnkey project.

Figure 1.1: Vessel Construction Options - DTC [Source: Damen Shipyards]

Clients can even choose delivery of turnkey projects and additional services such as job training, yard consul- tancy and yard upgrades. DTC recognises the same two projects (one-off and standards) in the same manner as the other business units, however, their projects are one of a kind. They allow clients to only buy vessel designs and material packages.

Even though the development procedures at DTC are quite different from standard procedures, the problems are also experienced by DTC.

Master’s Thesis 8 Irith Lely 1.2. SHIPBUILDING PROCESS This section introduces the general shipbuilding process, followed by explaining the differences in processes between one-off designs, standard designs and DTC (a business unit from Cluster New Build Division) pro- cesses.

The Damen shipbuilding process consists of three consecutive phases: concept development, execution and post development (see Figure 1.2). The blue arrows illustrate the different departments, the red squares repre- sent the shipbuilding phases.

Figure 1.2: General Shipbuilding Process [Sources: Damen Shiphards; Irith Lely]

1. Sales Management: sales, marketing, design, proposal & contract package 2. Project Management: detail engineering, supply chain, manufacturing & delivery 3. Services Management: after-sale (one year after delivery)

The Design & Proposal department (D & P) applies two types of design processes: the one-off design process (sometimes together with client, sometimes with the aim to develop a new standard) and the standard design process. For both processes, the client signs a contract package (see Figure 1.3).

Figure 1.3: Vessel Contract [Source: Damen Shipyards]

The vessel definition is captured in two annexes: the contract specification (booklet of 100+ pages, with all the standard and customised specifications of the vessel) and the general arrangement (GA, a drawing package describing the layout of the vessel). These documents are created by D & P (Design and Proposal), during the concept development phase. Should a client wish to adapt anything after the contract signing (during the execution phase or later), it has to be registered in a Variation To Contract (VTC). The following three documents capture the internal communication on vessel definition and project planning:

• contract specifications (booklet) • general arrangement (GA - drawing package) • cost price estimation (IDC - Integral Direct Cost)

Master’s Thesis 9 Irith Lely Damen uses IDC to calculate the project costs at the yard (see Figure 1.4). IDC separates product and non- product-related work packages, thus separating the vessel production costs from the product organisation costs.

Figure 1.4: IDC [Source: Damen Shipyards]

The contract specifications, general arrangement (drawing package), IDC and VTCs are used for both one-off and standard projects, however, their design processes differ.

One-off projects As client’s requests do not fit the characteristics of an existing Damen vessel, the concept development phase is much more elaborate and costly for one-off designs than for standard designs. To avoid higher risks of the concept development of one-off designs, Damen can let the client cover for the costs. The concept develop- ment of a one-off design with the involvement of the client follows the same process as new standard designs (without client involvement). One-off designs are focused on the client’s requirements and less on creating a multi-optional platform for new standard designs. During the design process of a one-off design with client, a project team is allocated to the project. With a new standard design, a D & P (design and proposal) engineer is allocated as product portfolio manager (PPM) to develop the new vessel type. The PPM is responsible for gathering information, creating new design ob- jectives and designing the new vessel. The information derives from contacts with the client and operators of predecessor vessel types, internal lesson learned documents and employees within Damen, with the fo- cus on sailing characteristics, human-ship interaction and (sub)system characteristics of different operational modes. Issues and positives are summarised and initial design criteria are formulated, resulting in contract specifications. The creation of the contract specifications, general arrangement and IDC take months. Due to the different client preferences and vessel complexities, the time indication varies considerably. Currently, design teams (one-offs) or the PPM (new standard vessels) use the design spiral (Figure 1.5). It is a recognised design method within the shipbuilding industry, exploited by several resources (further explained in Section 2.1).

Figure 1.5: Design Spiral [Source: Evans, 1959]

Master’s Thesis 10 Irith Lely Standard projects Often, the client request will fit the characteristics of an existing Damen vessel. Departing from the basic de- sign platform, the client can add multiple system options, lay-out changes or other specific requests, thus creating a semi-standard vessel design. The contract specifications, general arrangement and IDC (Integral Direct Cost) can be created within a few hours by one single D & P engineer (Design & Proposal).

Figure 1.6 represents the process of new standard designs. The Product Portfolio Manager (PPM) is supported by a design team. The one-off designs follow the same process, however with client involvement.

Figure 1.6: Design Process - New standard Designs [Source: Irith Lely]

The PPM has regular design control meetings with the head of D & P and sales, to monitor the design decisions of the PPM. Every meeting, the design spiral is further applied. When creating a new standard design, the PPM and sales approach potential clients to research the market attractiveness of the design. An interested client will sign the contract specifications. During an internal design review meeting, the PPM hands over the design with its implicit decisions to the project manager (PM) and head of engineering. This hand-over between PPM, PM and engineering is important to ensure the desired quality of the vessel.

DTC projects Generally, DTC (business unit of the Commercial New Build Division) is not fully involved in the concept de- velopment phase of Damen vessels. They receive the platform designs of specific business units, so-called ’source packages’. These packages require design adaptations before the vessel can be built on a DTC yard (re- mote location). D & P engineers from DTC are responsible for the (adjusted) contract specifications, general arrangement and IDC, which is the last step in the concept development phase.

Master’s Thesis 11 Irith Lely Based on the source package, contract specifications and yard requirements, DTC engineers perform a gap analysis. The results of this analysis are captured in a new, yard-specific package (Figure 1.7).

Figure 1.7: DTC - Design Gap [Source: Damen Shiphards]

DTC also executes one-off projects together with the client and a business unit. This is the case when the client desires a one-off vessel built on a yard not owned by Damen.

Master’s Thesis 12 Irith Lely 1.3. PROBLEM DEFINITION The following reoccurring problems at Damen are experienced during one-off and standard project types:

1. Ineffective external and internal alignment regarding product definition 2. Ineffective hand-over between PM and sales management 3. Insufficient quality control

This section will further elaborate on the problem definition. Understanding the problem is necessary to un- derstand the impact these problems have on Damen’s shipbuilding process (Section 1.4).

Ad 1a) Alignment client and Damen The demands of the client are captured in the contract specifications. There is misalignment of expectations between clients and Damen regarding the product definition, on topics such as quality and effectiveness of the vessel. Regularly, the client agrees on components, integrated systems, layout and quality with his own view on the vessel’s operation, thus interpreting the contract specifications according to his own expectations. On the other hand, Damen may misinterpret demands of the client when not getting deeper into the subject. When a vessel is not effective in achieving the client’s objectives, the client will flag this as a problem, known as the lack of effectiveness of the vessel (further explained in Section 2.1).

Ad 1b) Alignment subcontractors and Damen A vessel is divided in systems, subsystems and components, which are designed and manufactured by subcon- tractors. They have their own contracts, describing the requirements of their (sub)systems and components. Since the requirements are based on the insufficient general contract specifications, deficiencies occur dur- ing and/or after the assembly of (sub)systems and components. Damen is responsible for the coverage of the additional costs, unless specified otherwise in a subcontractor’s contract. Also, Damen often has to deal with delays in the development of the process because subcontractors do not always deliver on time or they do not always deliver the desired quality. Not getting the alignment regarding subcontractors first time right can have a great impact on the building process during the execution phase.

Ad 1c) Internal alignment The first problem concerns the product definition. The internal alignment on the product definition is based on the three documents created by Design & Proposal engineers (contract specifications, general arrangement and IDC - Integral Direct Cost). Due to the ’free’ interpretation of contract specifications, engineers may order wrong components, which can lead to hidden deficiencies and difficulties in the integration of systems. Hid- den deficiencies may result in problems relating to time and budget management. The second problem concerns time and budget control. The project planning and estimated required work- ing hours are captured within IDC. Although working hours are registered in IFS1 per project phase, the total amount of working hours spent on re-work is not defined. Therefore, time registration is not sufficient enough to pinpoint the exact location of the currently experienced problems and it is not possible to calculate the ex- act total of (re)working hours spent on the entire project. There are two views on the current time and budget control: D & P makes a wrong estimation resulting in time and budget shortages versus the execution phase is done wrongly, resulting in time and budget shortages. The third problem concerns the lack of responsibility on time reservation. D & P purposely tries to avoid tak- ing responsibility by only focusing on the components within the contract specifications.2 This statement is based on quotes such as (freely translated): "I would rather not define exactly what the temperature will be in the vessel, because we usually do not make the effort to calculate it as it is quicker and therefore cheaper to directly implement a previously installed HVAC system (Heating Ventilation and Air-Conditioning) of another vessel."3 In total, IDC consists of 70 percent material costs (including engineering hours) and 30 percent production costs. The total IDC budget only differs 2 to 3 percent4, which is acceptable to D & P engineers, thus not recog- nising the problem of adequate time reservation.

1IFS - Industrial and Financial Systems, a planning program. 2Interviews with TM, VL, JN, D & P engineers, HSC. 3Interview with TM, JN, VL, D & P engineers, HSC. 4Interview with BK, Manager D & P,DTC.

Master’s Thesis 13 Irith Lely Ad 2) Ineffective hand-over After completion of the concept development phase, the Product Portfolio Manager (PPM - standards and one-offs) or Design & Proposal engineer (D & P - standards) hands over the entire project to the project man- ager, who is responsible for the execution phase. In general, the hand-over of the contract package is done without elaborating on the implicit design decisions. Engineers may therefore develop systems that function differently than initially intended by the designer of the vessel (PPM or D & P).

Ad 3) Insufficient quality control Insufficient quality control (components, subcontractors and manufacturing process) during the execution phase, predominantly during the production phase, leads to late discovery of deficiencies.

See AppendixC for detailed examples of aforementioned problems, which have impact on the controllability, the quality and the effectiveness of a vessel. See Section 1.4 for an elaboration on the impact of the problems.

Master’s Thesis 14 Irith Lely 1.4. IMPACTOFTHE PROBLEM This section goes deeply into the impact of the reoccurring problems with ineffective external and internal alignments, ineffective hand-over and insufficient quality control. The impact can be divided into three major fields:

1. Controllability 2. Quality 3. Effectiveness

Controllability There is loss of control during the execution phase (detail engineering and production) because the contract specifications mainly consist of a list of components and there is not enough emphasis on the functional description of the working of the (sub)systems or vessel. When there is only a list of components, disci- plines/engineers will interpret these specifications in many ways, which may result in re-work and hidden deficiencies.

The reasons why specifications only consist of components are:

• The client is merely focused on the components, not enough on thoroughly discussing the operational profile. • Design & Proposal (D & P) experiences that some clients do not have enough expertise to completely describe the functional objectives of their vessels.5 • D & P indicates that when more time is taken to fill in the contract specifications, the risk of losing projects will increase, due to competitiveness of other (faster) shipbuilding companies.6 • Damen sometimes deliberately avoids to include functional descriptions in the contract to limit legal risk.7

As such, expectations of the client are not sufficiently registered in the contract specifications, which implies that both the client and Damen have less control during the execution phase (detail engineering and produc- tion). Variation To Contracts (VTCs) are necessary to further describe the client’s requirements, at the client’s costs. Since the contract specifications are incomplete, project management always has to negotiate on the definition of the vessel. When negotiations fail, VTCs are a last option. The impact of a VTC on the amount of work is often complex to predict and the client is almost never willing to pay extra. The bigger the number of required VTCs, the less control there is during the execution phase (detail engineering and production). To finalise the project to everyone’s satisfaction, project management has to choose between showing goodwill (thus making extra costs) versus referring to the contract specifications and informing the client Damen will only meet the requirements at the client’s costs (thus not satisfying the client).

Since time registration of previous vessels is not specific enough, D & P has not enough control over the quality of the Integral Direct Cost (IDC) of future vessels. Damen uses the program IFS to register the hours spent per project, to control the development and execution of projects. Since registration is not detailed enough (only the total amount of hours is known), one cannot establish what parts of the process are efficient and what parts of the process are subject to loss of quality. Project management and engineers indicate that project estimations done by D & P are often too tight in time and budget.8 D & P indicates that their estimations of the total IDC are only 2 a 3 percent off and therefore correct. Based on their experience, engineering is the most reliable actor to estimate how long it takes to add options (contract specifications) or make adjustments (VTCs), however, even they cannot predict the required time to the minute. According to engineering, D & P often does not take the time nor the effort to inquire about the exact time. Generally, they rely on previous experiences and assume the required time.9 Based on D & P’s statement "give an engineer a week and he will work and finish it in a week, give him a day and he will finish it in a day"10, they are tempted not to listen to the advice of engineers and create estimations that are too tight in time (and budget). Controlling projects starts

5Interview with TM, RL, D & P engineer at HSC. 6Interview with VL, D & P engineer at HSC. 7Interview with TM, VL, JN, D & P engineers at HSC. 8Interview with DP,DC, engineers at DTC. 9Interview with TM, manager engineering at DTC. 10Interview with JN, D & P engineer, HSC.

Master’s Thesis 15 Irith Lely with a reliable IDC, which depends on reliable time registration.

Ordering the appropriate components or systems from subcontractors, first time right, is crucial for the pro- cess. Damen is a system integrator, components are delivered by subcontractors. The engineering process strongly relies on information provided by subcontractors. Late disclosure can cause delay in engineering. Late delivery or delivery of (slightly) different components can cause delay in the production phase. Thus, there is less control of engineering and production. Hidden deficiencies are discovered late in the process and different components need to be (re)ordered; there is no longer control of the shipbuilding process.

Quality Deficiencies result in time and money-consuming rework. The insufficient quality control results in late dis- covery of deficiencies. When they occur before delivery of a vessel, project management experiences pressure to solve the issues on the one side and tries to stay within the project’s budget on the other side. When defi- ciencies occur after delivery, services weighs out goodwill against referring to contract specifications. Services closely co-operates with sales, to please clients involved in potential new projects. Services indicates that 10 to 15 percent of the warranty claims in reality is goodwill towards the client.11

The lower the quality, the higher the warranty costs. By combining the warranty costs and the ice-berg theory, the value of non-quality in 2016 is estimated at 30 million euros (versus a profit of 29.2 million euros), although the validity of this amount should be doubted.12 See AppendixD for further details of these costs.

Good quality also relies on a positive working attitude. Services indicates that they hear a lot of excuses from engineers, project management and sales as to why certain qualities of system integration have not been met. Employees of one department blame employees of other departments for deficiencies, time and budget short- ages or lower quality.13

Effectiveness Ineffectiveness is caused by inadequate design during the concept development phase, or by inadequate exe- cution during engineering and production.

Inadequate designs occur when:

• the client has insufficient knowledge of the desired functional description of the vessel; • Damen does not elaborate (enough) to inform the client on the functional behaviour of the vessel; • Damen does not invest enough effort in creating knowledge on the functional behaviour of new ves- sels during the development of new standards (they often decide to blindly copy systems from previous vessels into new ones).

Inadequate executions occur when:

• different disciplines interpret the contract specifications in their own way; • the hand-over between D & P and project managers (or even different project managers during hand overs) experiences loss of information; • there is lack of quality during the process and/or there are deficiencies in (integrated) systems.

11Interview with AK, Service Line Manager, Services 12Interview with MJ, Cost controller, Finance and Control. 13Various interviews with employees from D & P,engineering, services, HSE-Q and PM from the business units DTC and HSC.

Master’s Thesis 16 Irith Lely 1.5. SUMMARY,SCOPE,AIM &RESEARCH QUESTION Damen Shipyards (Damen) is a Dutch shipbuilding company founded in 1927 at Hardinxveld-Giessendam. They build, repair and refit vessels off all types, all over the world. The Commercial New Build Division (CNBD) recognises two types of projects:

• One-offs • Standards

The Design & Proposal department (D & P) carries out design processes for one-off and standard projects. The demands of the client are captured within the contract specifications and the general arrangement plan, cre- ated by the D & P department by applying the design spiral. D & P also produce the IDC (Integral Direct Cost), which contains amongst other things the estimation of required hours and costs. VTC documents (Variation To Contract) are used to adapt the contract. The contract specifications of standard vessels can be created in a couple of hours by one single D & P engineer.

The reoccurring problems of one-off and standard projects at CNBD are:

• Ineffective external and internal alignment regarding the product definition • Ineffective hand-over between sales management and project management • Insufficient quality control

The impact of the problems can be divided into three major fields:

• Controllability Loss of control during the execution phase (detail engineering and production): insufficient contract specifications, mismatches of expectations, inadequate time registration and inadequate hand-over. • Quality Hidden deficiencies, late or faulty delivery of components and lack of responsibility. The lower the quality, the higher the warranty costs. By combining the warranty costs and the ice-berg theory, the value of non-quality in 2016 is estimated at 30 million euros (versus a profit of 29.2 million euros), although the validity of this amount should be doubted. • Effectiveness Inadequate design (concept development phase) and inadequate execution (detail engineering and pro- duction).

Scope & Aim In accordance with Damen, the research focuses on the concept development phase of standard projects within the business unit High Speed Craft (HSC) with the aim to improve the effectiveness of the ship de- sign process. The problems encountered during the concept development phase and the execution phase are most likely to be solved by changing the concept development phase. The standard projects are chosen due to interest of Damen and the researcher, even though one-off projects experience the same problems (one-off projects are more trivial for application of systems engineering, due to the involvement of the client and the size of the projects). The majority of Damen employees are not tempted to recognise the value of applying a new approach for standard projects, which makes this research even more challenging. HSC is chosen because they build standard vessels, they are aware of the problems and they are open-minded towards this research.

Research question Though many theories exist, systems engineering (SE) has a particularly strong focus on the initial phase of the development of complex systems. SE seems an appropriate method to improve the external and internal alignments, project hand-over and quality control. Damen has interest in and some experience with the SE method (see Section 2.2).

Master’s Thesis 17 Irith Lely Based on the problem definition, the impact of the problems and the promising potential results of systems engineering, the research and sub-questions are:

In what way can systems engineering improve the effectiveness of the concept development phase of High Speed Craft standard projects?

1. What are the general design approaches in the shipbuilding industry? 2. What are the benefits of systems engineering? 3. What is the definition of the effectiveness of a shipbuilding process? 4. What is the current concept development process at High Speed Craft? 5. What are the differences between the current High Speed Craft concept development process and sys- tems engineering? 6. What is a suitable systems engineering framework for High Speed Craft standard projects? 7. What are the costs of performing systems engineering at High Speed Craft?

Master’s Thesis 18 Irith Lely 2 LITERATURE &RESEARCH

Based on the research of the theoretical background and the field research, this chapter provides answers to the sub-questions in chronological order.

Section 2.1 gives background information on general design approaches in the shipbuilding industry. Section 2.2 elaborates on the benefits of systems engineering. Section 2.3 defines the effectiveness of a shipbuilding process. Section 2.4 analyses the current concept development process of High Speed Craft (HSC) standard projects. Section 2.5 analyses the differences between the currently applied process at HSC and the general systems engineering process. Section 2.6 elaborates on the different methods of systems engineering and con- cludes with a suitable framework for HSC. Section 2.7 specifies the costs of performing systems engineering at HSC standard projects.

2.1. GENERAL DESIGN APPROACHES This section provides an answer to sub-question 1: What are the general design approaches in the shipbuilding industry?

Section 2.1.1 explains complexity in ship design and the necessity of an overarching design approach, Section 2.1.2 shows the iconic design spirals, Section 2.1.3 elaborates on a selection of researches trying to improve the presentation of the design spiral is presented and Section 2.1.4 gives a brief introduction to systems engineer- ing.

2.1.1. COMPLEXITY To be able to choose a design approach, one must first establish the complexity of the systems and projects, which is defined during the introduction of the course Design of Complex Specials (master course Technical University of Delft; Kana, 2016). They quote Andrews (1998) and Shields et al. (2016). Andrews (1998, p. 187) defines: "The design of physically large and complex systems is a wicked problem. A wicked problem means that the problem is not understood until after the formulation of a solution. Further- more, a wicked problem has no stopping rule or final optimum, and different solutions are not necessarily right or wrong. Every wicked problem is unique and every solution to a wicked problem is a ’one shot opera- tion’ as no full scale of prototyping is possible." Shields et al. (2016) give another definition of a complex product, by listing three aspects:

1. The solution landscape can be seen as a dancing landscape. It is not one single peak or optimum, with one optimal solution. In contrary, there are multiple solution possibilities that change during the course of problem solving and solution development is therefore depicted as a ’dancing and dynamic land- scape’. 2. Emergent behaviour: (a) Unknown behaviour emerges during design and operation (e.g. a watch has complex components but no complex behaviour). (b) Design activities are typically complex. 3. Unknown interdependencies: need to test entire system to understand individual components.

Both definitions contain the problem solution as a criterion for being a complex project. Both Andrews (1998) and Shields et al. (2016) refer to multiple component interactions and levels of subsystems to describe the difficulty of understanding and predicting system operation and operational effectiveness (alias, the problem solution space). Due to the dancing and dynamic landscape of solutions and the unknown interdependencies,

Master’s Thesis 19 Irith Lely traditional ship design approaches are developed in point-based design methods (see Section 2.1.2).

A vessel is considered a complex system as it is a set of interrelated components working together towards multiple common objectives. The part multiple common objectives is subject to discussion for a lot of Damen vessels. For example, the Fast Crew Supplier only has the objective to transport equipment or crew, the tug only has the objective to tow. Vessels such as dredgers or complex marine vessels, though, serve multiple ob- jectives. In the way the design platforms are created, one could argue that they must serve as platform for multiple types of vessels, thus serving multiple objectives. Interrelated components are developed by multiple different technical disciplines, working together or parallel. There is no optimum in ship design as it can be seen as a ’wicked’ problem. It is also considered complex since most vessels are one-off projects and the phys- ical size or cost size results in difficulties with prototyping.

2.1.2. DIFFERENT DESIGN SPIRALS According to McKenney (2013), the definition of a design approach is: "the overarching guiding principles of a design effort." Traditionally, the ship design process is presented by the design spiral. The spiral is a sequential, point-based design approach, focused on designing towards one optimum in an iterative way. The design spiral is also embedded in the Damen ship design process and is explored by many researchers.

• Many literature sources related to concept development of ships refer to Evans (1959) being the first to present the process of ship design in a spiral (see Figure 2.1).

Figure 2.1: Design Spiral Evans [Source: Evans, 1959]

• Watson (1998) defines two different design spirals, one for merchant ships and one for (see Figure 2.4). The differences, however, are small, they only contain different names such as ’total dead- weight’ versus ’variable weights’. The input of the design spiral are the operational requirements. This thesis uses the term operational objectives, where an objective is a description of the operation itself or the description of the end state. The operational requirements are the input for the iterative process of defining the description of the vessels characteristics and systems, captured by the design requirements and gathered in the contract design. Design requirements describe the vessel dimensions, lay-out and systems, which after every cycle of the spiral, will be optimised. Therefore, this method is called point- based design, where the designer will optimise towards one single point. During the execution of this design, the operational objectives (requirements) are not optimised or con-

Master’s Thesis 20 Irith Lely sidered within every cycle. For example: description of cargo handling is operational objective, the re- quirements concerning stability and deck space are requirements. Watson further indicates that the spiral should not be thought of as showing the exact order in which the different aspects of design should be tackled: this will depend on the type of ship being designed. Some ships will have weight critical design requirements. Other options for critical requirements are volume, deck area, linear dimensions (length, width, height, depth), stability, speed and/ or seakeeping characteristics, tonnage and so forth.

Figure 2.2: Design Spirals Watson [Source: Watson, 1998]

• According to Rawson & Tupper (2001, p. 653), the process is iterative and converges upon the final solu- tion. This can only be achieved by going over the elements repetitively until they all match.

Figure 2.3: Design Spiral Rawson & Tupper [Source: Rawson & Tupper, 2001]

• Papanikolaou (2014) states there are four main phases of ship design: concept design - feasibility study, preliminary design, contract design and detailed design. He presents an approach of a straightened design spiral, striving to reduce the number of design iterations.

Master’s Thesis 21 Irith Lely Figure 2.4: Design Spiral Papanikolaou [Sources: Papanikolaou, 2014]

Apart from slightly different terms, all spirals are quite similar, however, the differences are whether the oper- ational objectives or mission is part of the optimisation process or whether they are the starting point of the optimisation.

2.1.3. SPIRAL IMPROVEMENTS The design spiral is often referred to as the ’over-the-wall’ approach, where the ’wall’ is situated between de- sign and manufacturing (Boothroyd et al., 2002). The concept and preliminary design focuses mostly on the product and its complexity. Design for Production, Manufacturing Assembly, Six Sigma and Lean are devel- oped later, to lower this wall by focusing more on the production process.

Bruinessen et al. (2013, p. 10) state that the design-spiral describes the increasing level of detail during the de- sign process, however, it does not responding to changing system choices, solutions or requirements. By using the design spiral, the design choices that have the most impact are made before the design spiral commences. The initial input of the general design diagram presented by Evans (Evans, 1959) is a General Arrangement, implying that the design of the ship, in essence, forms the input of the spiral. The spiral process addresses mainly the engineering of the vessel, once the main design choices have been made.

Like Papanikolaou (2014), many other researchers have tried to improve the design spiral. The following list is a selection of researchers trying to improve different aspects of the concept development phase of ship design.

• Oers (2011) assumes the design requirements are given and developed "the packing approach" in order to "reduce the effort required to generate and investigate a large number of alternative ship designs during the early stage design of service vessels." • Moredo & Krikke (2010) thrive to improve the re-use of design data during tender phase. Their method- ology consists of the implementation of two novel structures: a Functional Breakdown Structure and a System Breakdown Structure. The first provides a tool to capture key data, that is currently missing, for the re-use at an early stage of design. The second structure ensures that the design data is structured, documented and easy accessible and retrievable for new tenders. The two structures are linked to ensure the traceability and re-usability of design data for new tenders. • Erikstad & Rehn (2015, p. 324) characterised the conceptual ship design task as a complex system prob- lem and proposed a general approach to handle this complexity, based on decomposing and encapsulat- ing. They introduced and applied five aspects of complex systems to the early stages of conceptual ship design and they discussed several traditional and novel techniques to handle the information related to these five aspects. They used the design of an OSV (Offshore Support Vessel) as example. • DeNucci (2012) dedicated his dissertation to improving conceptual ship design by capturing the de- sign rationale, which embodies the reasoning and justification behind design decisions. DeNucci (2012) states: "The Rationale Capture Tool developed in the dissertation can be used to capture the rationale behind object interactions. In addition, previously captured rationales can be applied as constraints for generating new arrangements. During the review process, the tool can be used as a substitute for formal

Master’s Thesis 22 Irith Lely design meetings. Post design, the tool can be used to capture lessons learned. The RKC methodology might also have potential for capturing rationale in other stages of the design process. Ultimately, the approach developed in this research improves the quantity of knowledge available in the early stages of the design process. This not only helps preserve the industry’s fleeting knowledge, but also provides a foundation for making improved decisions in the ship design process." • McKenney (2013) presents a novel set reduction decision support framework for large-scale, team-based design efforts. The framework provides a design manager with valuable and clear information to make better informed reduction decisions within a set-based design (SBD) environment. McKenney (2013) states: "SBD is a convergent design method that uses dominance and infeasibility to consider multiple design alternatives in parallel while accommodating separate groups of specialists within a concurrent engineering approach." • Nieuwenhuis (2013) evaluated the appropriateness of product platforms for Engineered-To-Order ships, in order to improve the re-use of design data and therefore speed up the concept design process. • Killaars (2015, p. 158) tried to apply network science to control the interactions between ship elements in ship design. • Gasper et al., (2012) present strategies to handle complexity during the conceptual phase of ship design. The presented general approach is based on decomposition and encapsulation. Furthermore, five main aspects of complexity are presented (structural, behavioural, contextual, temporal and perceptual), link- ing challenges of the conceptual phase to each of the aspects. • McKenney (2013) summarises the Concurrent Engineering (CE) method as follows: "CE directly conflicts with traditional design practices where the design is passed along with consideration of one set of factors at a time. CE introduces Integrated Product Teams (IPTs) and co-location to improve communication. An IPT is a group that is comprised of experts from many disciplines that work together and are collectively responsible for a particular product design effort. Co-location is the placement of all people involved on a project in the same physical location. Typically, downstream activities, such as manufacturing, are able to be initially considered during primary design stages using CE (Sobek, 1997). Figure 2.5 provides a visual depiction of the development process using CE. The main advantages of CE include lower cost, higher quality, shorter time to market, and less re-work (Bennett & Lamb, 1996; Addo- Tenkorang, 2011). The “wall” discussed in the previous section is lowered substantially using CE. CE does not change the design process, but addresses concurrent communication and coordination needs for any type of process."

Figure 2.5: Concurrent (Parallel and Integrated) Product Development [Source: Bennett & Lamb, 1996]

The trend to find design approaches with faster ways of finding the ’optimal’ solution is proved by the extended list of recent researches shown above. Some researches focus more on improving creativity and decision mak- ing, others focus more on the controllability of the process.

Master’s Thesis 23 Irith Lely 2.1.4. SYSTEMS ENGINEERING Concurrent engineering and Set-Based Design are based on parallel working, systems engineering takes the same design approach of parallel working a step further. The International Council on Systems Engineering (INCOSE, n.d.) gives the following definition of systems engineering:

"An interdisciplinary approach and means to enable the realisation of successful systems. [...] Systems Engi- neering considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs."

According to Kossiakoff et al. (2011), the function of systems engineering (SE) is to guide the engineering of complex systems. Systems engineering is known for considering all likely aspects of a project or system, over the whole life cycle of the product. Due to the nature of the approach, SE is mostly used for the development of complex products such as aeroplanes, trains, cars, software, defence systems and civil constructions. The most famous example of systems engineering is the flight software of the Apollo, designed by Team Margaret Hamilton1 (NASA, 2007). On top of that, the U.S. Department of Defence (DoD) is known for successfully im- plementing systems engineering techniques for the development of naval ship design (Calvano et al., 2000). Closer to home, six Dutch major civil engineering companies bundled their systems engineering knowledge to write multiple guidelines for SE applied within the civil engineering sector (Leidraadse, n.d.).

In general, naval ships are often designed by a systems engineering approach as stated by Moredo & Krikke (2010). They also state that the SE approach developed for naval vessels can be used for commercial vessels, but up to now there are no generic examples in literature. This statement is confirmed by Vries (2015) in his paper on SE at Damen Schelde.

During the general design process of systems engineering, three important iterative steps are taken:

1. Defining the (operational) objectives of the vessel. 2. Defining the functional requirements of the (sub)system. 3. Defining the physical description of the vessel and components.

It is important to define a complete list of objectives, to allocate every objective to a functional requirement and to allocate functional requirements to physical subsystems and components (see Figure 2.6).

Figure 2.6: Allocation of Functional Requirements to Systems Breakdown [Source: Leidraadse, n.d.]

A functional requirement can be defined as: identifying the way a (sub)system functions, by describing the inputs, behaviour and outputs. This must be done without implicitly indicating the components or lay-out of the system.

The allocation between operational objectives, functional requirements and the system breakdown is crucial and must be complete. When a functional requirement cannot be allocated to a higher objective, it serves no purpose and must be removed. Functional requirements can be allocated to multiple components and

1Margaret Hamilton (1936-), American computer scientist, systems engineer, business owner.

Master’s Thesis 24 Irith Lely (sub)systems. And the other way around, components and (sub)systems can serve multiple operational ob- jectives.

In order to quantify the effectiveness of a vessel, the operational objectives and functional requirements must be validated. This can only be done when the measure of effectiveness (MOE) and the measure of perfor- mances (MOP) are defined. According to Kossiakoff et al. (2011), the definitions of the MOE and MOP are:

• MOE: A qualitative or quantitative metric of a system’s overall performance that indicates the degree to which it achieves its objectives under specified conditions. A MOE always refers to the system as a whole. • MOP: A quantitative metric of a system’s characteristics or performance of a particular attribute or sub- system. A MOP typically measures a level of physical performance below that of the system as a whole.

Since operational objectives define the system goals of the complete vessel they are one-on-one related to the definition of MOEs. The functional requirements are requirements related to the behaviour of (sub)systems; they are one-on-one related to the definition of MOPs.

Conclusion The definition of a design approach is the overarching guiding principles of a design effort. To be able to choose a design approach, one must first establish the complexity of the systems and projects. A vessel is con- sidered a complex system as it is a set of interrelated components working together towards multiple common objectives. The multiple common objectives are subject to discussion for a lot of Damen vessels. Interrelated components are developed by multiple different technical disciplines, working together or parallel. There is no optimum in ship design for it can be seen as a ’wicked’ problem. It is also considered complex since most vessels are one-off projects and the physical size or cost size results in difficulties with prototyping.

The ship design process is presented by the design spiral, a sequential, point-based design approach, focused on designing towards one optimum in an iterative way. The design spiral is embedded in the current Damen ship design process. Four design spirals are studied (Evans, Watson, Rawson & Tupper and Papanikolaou). They are all quite similar, however, the differences are whether the operational objectives or mission is part of the optimisation process or whether they are the starting point of the optimisation. Many researchers try to find design approaches with faster ways to find the ’optimal’ solution. Some focus more on improving creativ- ity and decision making, others focus more on the controllability of the process.

Concurrent engineering and Set-Based Design are based on parallel working, systems engineering (SE) takes the same design approach of parallel working a step further. The function of SE is to guide the engineering of complex systems. SE is known for considering all likely aspects of a project or system, with a strong focus on customer needs, over the whole life cycle of the product.

The general SE design process consists of three important iterative steps: defining the operational objectives of the vessel (MOE, measure of effectiveness), the functional requirements of the (sub)system (MOP,measure of performances) and the physical description of the vessel and components. The allocation between objec- tives, functional requirements and the system breakdown is crucial and must be complete. When a functional requirement cannot be allocated to a higher objective, it serves no purpose and must be removed. Functional requirements can be allocated to multiple components and (sub)systems. And the other way around, compo- nents and (sub)systems can serve multiple operational objectives.

Master’s Thesis 25 Irith Lely 2.2. SYSTEMS ENGINEERING &BENEFITS This section provides an answer to sub-question 2: What are the benefits of systems engineering?

Systems engineering (SE) is known for the systematic and complete approach of describing operational ob- jectives (MOE, measure of effectiveness), functional requirements (MOP, measure of performances) and the constant verification and validation along the complete life cycle of the design (see Section 2.5). The approach aims to create products that are aligned with the clients’ needs. This goal is achieved by the precise and com- plete description of operational objectives and functional requirements. In this way, all parties involved are better aligned and hand-over is far more transparent.

Multiple sources conclude with a list of benefits when performing SE. According to the civil guideline, SE en- sures the following.

1. Concept of operations is properly understood:

(a) System functions are clear (b) System layout is clear (c) System components are clear (d) System modes are clear (e) System automation is clear (f) Limitations and constraints are clear (g) Related systems are clear (h) Maintainability is considered

2. Regulatory aspects are considered. 3. Required documentation is considered. 4. Hazard & Safety aspects are considered. 5. Customer expectations and suppliers’ promises are aligned.

These benefits implicate that systems engineering has the potential to improve the external and internal align- ments.

Kossiakoff et al. (2011) conclude that the following aspects of SE are typical/beneficial.

• SE is focused on the system as a whole. • SE is concerned with customer needs and operational environment. • SE leads system conceptual design. • SE bridges traditional engineering disciplines and gaps between specialities.

Kossiakoff et al. (2011) state: "Systems engineering is an integral part of project management in that it plans and guides the engineering effort." They focus more on the process part of product development, which im- plicates that SE has potential to improve both the hand-over between sales and project management and the controllability of the process.

Practising SE implies high costs and there are degrees in applying formal systems engineering processes. The costs of performing formal SE processes together with the costs of different risks due to product or system integrity will together result in the project/program cost. The optimum lies in the balance between these two; per enterprise or product this balance needs to be established. Haskins (2006) continuously expresses all pro- cesses need to be tailored to each company and product (see Figure 2.7).

Master’s Thesis 26 Irith Lely Figure 2.7: Tailoring requires balance between risk and process [Source: Haskins, 2006]

SE at Damen The following three projects are examples of Damen’s interest in and experience with the SE method. The first is a research executed by Vries (2015), the second a warship project and the third the V & V workstream.

Vries followed the Damen Leadership Development Course (II) at Nijenrode Business University and used his experience gained at Damen Schelde, to write a paper on implementing systems engineering into Damen Schelde (Vries, 2015). The aim of the paper is to develop a commonly accepted systems engineering method for Damen Schelde, which can be implemented over all engineering groups in a later stage. The paper starts with an introduction into systems engineering followed by a brief overview of three projects and it explains why systems engineering was proven beneficial for these projects. SE proofed to be a serious improvement for the overall project, resulting in a fast building process with less re-work. The output of the systems description was regarded as a valuable input for other documentation and processes. The paper concludes that Damen Schelde will implement SE. It predicts that CNBD will experience more resistance from the engineers to imple- ment SE but that they would also benefit from using systems engineering techniques, especially for Offshore & Transport and one-off or standard designs. See AppendixE for a brief summary of the paper. This master’s thesis is focused on HSC, and therefore follows the recommendation of Vries (2015) to research implementation of SE on standard HSC projects at Commercial New Build Division (CNBD).

The warship is a project run at CNBD. The project was run until the complete concept development phase was finished, after which the local government decided not to build the vessel with Damen. In this project, the client forced a systems engineering approach, which was also the case with the three Damen Schelde projects described by Vries (2015). The request to have all test documents ready and allocated to all functional require- ments before the start of detail engineering was completely new to Damen. See AppendixF for a summary of the project. This master’s thesis uses the knowledge gained from this one-off project and extends the insights by applying it on standard HSC projects at CNBD.

The workstream Verification & Validation (V & V) evolved from the Organisational Value Analysis (OVA). The goal of the OVA is to understand the potential efficiency gains in the short and medium term, to eliminate the non-added value costs and structurally improve the quality of processes, systems and people. Workstreams relate to different parts of the shipbuilding process: IT, Quality, Supply chain management, sales, planning and management. The last work stream is called Verification & Validation (V & V), aiming for implementing systems engineering within CNBD. All workstreams plans will be implemented in 2018. AppendixG gives extra background information on the V & V project. This master’s thesis supports the goal of the V & V workstream and complements it by researching standard HSC projects at CNBD.

Master’s Thesis 27 Irith Lely Conclusion Due to its benefits, systems engineering has a strong potential to improve the external and internal alignments, the hand-over between sales and project management and the controllability of the shipbuilding process. Hence, systems engineering has the potential to improve the theoretical expected result and the theoretical expected effectiveness of the concept development phase.

In a previous Damen project, SE proofed to be a serious improvement, resulting in a fast building process with less re-work. The output of the systems description is regarded as a valuable input for other documentation and processes. The drawback is that practising systems engineering implies high costs. Finding the correct degree in application of the engineering process takes time and effort.

Master’s Thesis 28 Irith Lely 2.3. EFFECTIVENESS IN SHIPBUILDING PROCESSES This section provides an answer to sub-question 3: What is the definition of the effectiveness of a shipbuilding process?

According to Veeke et al. (2008), a process is "a series of transformations that occur during throughput which result in a change of the input elements in place, position, form, size, function, property or any other charac- teristic."

To be able to define the theoretical effectiveness of a process, it is important to understand the terms used in the formula. According to Veeke at al. (2008), the definitions are:

1. Rintended : "The intended result, the goal of the process set by the company." 2. Rexpected : "The theoretical expected result, which is dependent on the ways and methods of the chosen approach." 3. Ractual : "The actual result, only known after executing the process."

Ef fectivenesstheoretical : "Theoretical effectiveness of the process is defined as a relationship between two results, the expected and intended result" (Veeke et al., 2008), see Figure 2.8.

Figure 2.8: Theoretical Effectiveness [Source: Veeke et al., 2008]

When the theoretical effectiveness is less than 1, the approach is no longer interesting. It is crucial to clearly define the intended result, to be able to select the appropriate approach. One must also examine the sacrifices that have to be made in order to obtain the expected result. There are two types of sacrifices (S):

1. Expected sacrifice 2. Actual sacrifice

There is no such thing as intended sacrifice, as the intent will always be to lower the actual sacrifice to a min- imum. The term sacrifice is complex. One can e.g. invest more money in better means, resulting in avoiding human sacrifices such as the need to work in an unhealthy or tiring work situation. When individuals are ex- periencing less sacrifices, usually the systems covers this with sacrifices. The goal is to create the highest result with the lowest sacrifice. The relation between the result and sacrifice is called "productivity" (P), see Figure 2.9.

Figure 2.9: Actual Productivity [Source: Veeke et al., 2008]

The actual productivity of a process is not complex to grasp, being a straight foreword ratio. However, only after having carried out a process one knows the actual result and thus the actual productivity.

The theoretical maximum productivity is defined by the ratio between the maximum actual result and the minim actual sacrifice experienced during the same approach and conditions (see Figure 2.10). When a pro- cess reaches a new maximum result with a constant sacrifice, or a new minimum sacrifice with a constant result, this then becomes the new standard result, standard sacrifice and thus standard productivity.

Figure 2.10: Max. Theoretical and Standard Productivity [Source: Irith Lely, based on Veeke et al., 2008]

Master’s Thesis 29 Irith Lely The ratio between the expected and actual sacrifice in order to reach the same result, is called efficiency (see Figure 2.11).

Figure 2.11: Efficiency [Source: Veeke et al., 2008)

It is important not to confuse the terms efficiency (S/S) and effectiveness (R/R). Not all approaches have the same theoretical effectiveness, and optimising the efficiency of an ineffective or less effective approach results in ’aimless efficiency’. The goal of this research is not to achieve great efficiency, but to higher the effectiveness by improving the theoretical expected result.

Because of the strong relation between the actual result and the actual sacrifice, the actual effectiveness is not the ratio between the actual and intended result but the ratio between the actual and standard result, see Figure 2.12. Actual effectiveness can only be compared when one assumes the sacrifices are constant.

Figure 2.12: Actual Effectiveness [Source: Veeke et al. (2008)]

Conclusion For this thesis, the actual result and actual sacrifice of executing systems engineering during the concept de- velopment phase are not known until the process has been executed. This is the reason why the actual effec- tiveness cannot be disclosed. The theoretical effectiveness, however, can be defined.

The intended result is implicitly defined during the problem definition. The following list represents the in- tended result of the concept development phase of HSC standard projects:

• Proper documentation for effective external and internal alignment on the product definition. • Effective hand-over between sales management and project management. • Appropriate system definitions to enable sufficient quality control.

When the theoretical effectiveness (R/R) of implementing systems engineering scores higher than 1, the ap- proach is interesting. The theoretical productivity (R/S) also has to be taken into account. The actual pro- ductivity (R/S) and the efficiency (S/S) are factors that should be monitored during and after the execution of processes.

Master’s Thesis 30 Irith Lely 2.4. CURRENT CONCEPT DEVELOPMENT This section provides an answer to sub-question 4: What is the current concept development process at High Speed Craft?

To enable comparison of the current HSC design process of the concept development phase, two recently de- signed HSC vessels were investigated. One vessel is a small Fast Crew Supplier (FCS) with an overall length of approx. 30 meters, the other one is the largest new FCS with an overall length of approx. 60 meters. Both vessels evolved from smaller predecessors. For confidentiality reasons, the vessels are named small FCS and big FCS. Research was done by looking at the initial design documents, in combination with interviews with project portfolio managers (PPMs).2 Apart from that, Design & Proposal engineers were interviewed3 because they use the design platforms on a daily basis to create new contract specifications.

Design process of small FCS The PPM followed the procedures of a new standard design (see Figure 1.6). First of all, he created a document with a summary of the deficiencies of approx. 30 smaller predecessors. The inputs of multiple companies were gathered into an elaborate list of positive and negative characteristics. Based on the summary, the initial design criteria were created, by executing the design spiral. After every (couple of) cycle(s) of the spiral, the PPM updated the initial design criteria document and reported the outcome during a design check meeting with the head of Design & Proposal (D & P) and sales. The sequence of these meetings were defined at the start of the project in collaboration between the PPM and the head of D & P engineering.

The initial design criteria of the small FCS (see AppendixK) contain objectives such as range, area of service, top speed and capacity (dimensions of equipment and number of crew). This document is the first document containing ideas and objectives for the new design. At every update, the content is more precise. This docu- ment has the same setup as the contract specifications, items are grouped per system code (see figure 2.13).

Figure 2.13: System Codes Damen [Source: Damen Shipyards]

2Interviews with TM & SN, PPM - D & P engineer at HSC. 3Interviews with VL, NB, D & P engineers at HSC and DTC.

Master’s Thesis 31 Irith Lely Some design criteria of small FCS The following example shows parts of the design criteria of the sailing profile and propulsion during the con- cept development phase (see AppendixK for the complete document). The italic remarks underneath the figures are terms used in systems engineering (see Section 2.1).

• Objective of the vessel (Possible) Tasks of the Damen FCS: Wind Farm Support Vessel and Diving Support Vessel. • Fuel capacity (see Figure 2.14)

Figure 2.14: Example System Codes Damen - 000 capacities [Source: Damen Shipyards]

’Capacity based on sailing profile sustained for 1 week’ is already an engineering solution, in fact a vessel objective on the sailing profile. • Sailing profile (see Figure 2.15)

Figure 2.15: Example System Codes Damen - 000 Sailing Profile [Source: Damen Shipyards]

The specifications on range and area are vessel objectives on the sailing area; speed is a functional re- quirement of the vessel. At the end of the document the combination of the hull resistance and the installed power gives the resulting sailing characteristics. • Propulsion (see Figure 2.16)

Figure 2.16: Example System Codes Damen - 200 [Source: Damen Shipyards]

Description of two arrangements and their selection criteria are explained (210). The final contract spec- ifications contain the types and brand names, presented in the same manner.

Master’s Thesis 32 Irith Lely • Hull shape (see Figure 2.17)

Figure 2.17: Example System Codes Damen - Hull shape [Source: Damen Shipyards]

Information on the hull shape is scattered throughout the document. The first page states the main dimensions of the vessel. Further on in the document, it contains the following information: Large wet deck clearance over the whole length of the vessel (high tunnel) to postpone/prevent the occurrence of slamming (000 General, second bullet). This is an objective of the hull shape. In row 000 Tunnel clearance, the tunnel is further specified; this is in fact an engineering solution. These two specifications are not allocated to each other. Another example: The description of the tunnel clearance of the predecessor of the small FCS was not explicit enough nor allocated to big components. This resulted in a too heavy design, resulting in a tunnel clearance that was too low. The sailing characteristics were therefore not as promising as the hull design should be and re-work was required. When designing the current version of the small FCS, this description was rectified.

The initial design criteria form the basis for the contract specifications that are leading for the client and Damen when building the vessel. They mostly consist of definitions of components. Also, the general ar- rangement is a result of the concept development phase. Together with IDC (Integral Direct Cost), these are handed over to project management, however, how this is done is not decided within set procedures.

Design process of big FCS Conversations indicate that the initial design criteria document of the big FCS is similar to the one of the small FCS 4. Due to the size and design challenge of a high top speed of the big FCS, the design spiral was done by the Product Portfolio Manager (PPM) in co-operation with two extra (mechanical and maritime) engineers, during a couple of months. They together updated the initial design criteria document and reported the out- come during design check meetings with the head of Design & Proposal and sales. Unfortunately, the PPM was

4Interview with SN, PPM - D & P engineer at HSC.

Master’s Thesis 33 Irith Lely not able to produce the initial design criteria of the big FCS. Only the contract specifications and the GA were available, which were organised via the system codes and mainly consists of component definitions.

Conclusion In the current document with design criteria, information is at times vague and scattered throughout the doc- ument, without direct allocation to each other. The result of the concept development phase are the contract specifications and general arrangement. The current contract specifications mainly consist of a list of com- ponents, not necessarily describing the operational objectives and functional requirements. This may lead to misinterpretations and costly re-work.

In view of the defined intended result of the concept development phase and the way the current process is designed, the following results are not expected.

• Proper documentation for effective external and internal alignment on the product definition. • Effective hand-over between sales management and project management. • Appropriate system definitions to enable sufficient quality control.

Since the intended results are higher than the expected result, the effectiveness of the current concept devel- opment phase can be defined as lower than 1. The actual results proved to be the same as the expected results, because of the experienced problems during the execution phase of new standards and copies of existing standards.

When developing a new standard vessel, HSC makes the following sacrifices.

1. Expected sacrifice: low sacrifice during concept development phase, low sacrifice during execution phase 2. Actual sacrifice: low sacrifice during concept development phase, very high sacrifice during execution phase

Whether the expected and actual sacrifice differ, must be traced back case by case. Currently, the expected sac- rifice of the development of new standard vessels is not defined. Therefore, the efficiency (S/S) of the current concept development of standard vessels cannot be defined.

When copying an existing standard vessel, the expected sacrifice is very low, as the contract specifications can be created within a couple of hours. However, the result is expected to be the same as during the development of new standard vessels. When copying a predecessor, HSC makes the following sacrifices.

1. Expected sacrifice: a couple of hours, during the concept development phase, lower sacrifice during the execution phase than with new standard vessels 2. Actual sacrifice: a couple of hours during the concept development phase, much higher sacrifice during the execution phase, like with new standard vessels

Currently, the efficiency (S/S) of the copying process of existing standard vessels is not defined, however, this can be determined when the expected sacrifice is defined in a quantifiable manner and the actual sacrifice is measured.

Figure 2.18 gives an overview the results and sacrifices of the current concept development of new standards versus copied standards. The height of the amount of result and amount of sacrifice is presented by a number of units (respectively circles and squares), where more units means an higher result or a larger amount of sacrifice.

Figure 2.18: Current Results & Sacrifices [Source: Irith Lely]

Master’s Thesis 34 Irith Lely Even though employees of High Speed Craft would expect higher results, research into the current concept development phase with its reoccurring problems indicates that executing the current process will give an ex- pected result as shown above. Both for new standards and copies standards, the theoretical effectiveness (ratio of intended and expected result) is lower than 1.

The efficiency of the concept development phase is for both processes 1 or higher, however, the efficiency of the execution phase is proven to be very low. This is expressed by the high amount of actual sacrifice versus the low expected sacrifice.

The actual productivity of both processes is 1. However, due to the high amount of sacrifice, the actual pro- ductivity of the execution phase, as well as the total actual productivity, are all lower than 1.

Master’s Thesis 35 Irith Lely 2.5. DIFFERENCES CURRENT SITUATION AND SYSTEMS ENGINEERING This section provides an answer to sub-question 5: What are the differences between the current High Speed Craft concept development process and systems engineering?

Should systems engineering (SE) have been applied, primarily based on Kossiakoff et al. (2011) and Leidraadse (n.d.), the representation of design criteria of the small and big FCS would have been different.

Design process of small FCS To illustrate the differences, the current design criteria of a small FCS are translated into SE, see Figure 2.19.

Figure 2.19: Info from Figures 2.14 through 2.17 translated into Systems Engineering [Source: Irith Lely]

• Operational objectives (MOEs) In this example, transport crew is the overarching objective, the sailing profile is a primary objective, consisting of three sailing areas. These areas are further explained in the secondary objectives: bow landing (sailing with the bow against the wind turbine) and transit phase. These two profiles have differ- ent objectives they must fulfil. Required (sub)specifications are allocated to the appropriate objective. • Functional requirements (MOPs) In this example, two requirements are specified: propulsor & steering and hull shape (resistance). Re- quired (sub)specifications are allocated to the appropriate requirements. • Systems breakdown (components) In this example, only the shipbuilding hull (100) and the propulsion (210) have been defined (see further explanation in the fields behind the blue arrows in this section).

One must take into account that the hull shape and volume (resistance), in combination with the installed power, will have influence on the resulting speed of the vessel. Allocations must be done with great care and must be complete, in order to avoid basic design mistakes.

Design process of big FCS Unfortunately, the PPM could only produce the contract specifications and the general agreement of the big FCS, not the initial design criteria. Therefore, the original operational objectives and functional requirements are unknown and an example as shown above cannot be made. Within SE, this could have not been possible. The designer would have had to create and allocate operational

Master’s Thesis 36 Irith Lely objectives with functional requirements, which implies that the design goals would always be comprehensible and traceable by all parties involved (designers and engineers).

Conclusion The current concept development process merely focuses on defining components. The description of oper- ational objectives and functional requirements of subsystems is hardly done, especially not in the structured manner of systems engineering (SE). There is no allocation between the objectives and the requirements, a must in SE to ensure all design goals are traceable. Currently, information is scattered throughout the docu- ment, making the whole less comprehensible, possibly causing misinterpretations, hidden deficiencies result- ing in costly re-work.

When applying SE in general, operational objectives are precisely defined and allocated to functional require- ments of subsystems. Since operational objectives and functional requirements are precisely defined, infor- mation will be comprehensible to all parties involved, thus avoiding misinterpretations and hidden deficien- cies. Also, the design objectives will always be traceable. In principle, components are not specified during the concept development phase, this will be done during the execution phase (detail engineering).

The difference of work between the current process and the general SE process, is the extra expected sacrifice. Figure 2.20 gives an overview of differences between the results and sacrifices of current standard projects versus the general systems engineering process (based on other industries). The height of the amount of result and amount of sacrifice is presented by a number of units (respectively circles and squares), where more units means an higher result or a larger amount of sacrifice.

Figure 2.20: General Systems Engineering - Results & Sacrifices [Source: Irith Lely]

The intended, expected and actual result of systems engineering are all the same during the concept devel- opment and execution phase. According to Kosskiakoff and Leidraadse, this is due to the controllability SE provides. Sacrifices of SE processes are high during the concept development and low during the execution processes. The total productivity, however, (both actual and expected) are 1. Comparison of the efficiency of the general SE processes does not give much insight, since sources indicate that expected sacrifices and actual sacrifices are the same.

Master’s Thesis 37 Irith Lely 2.6. SYSTEMS ENGINEERING FRAMEWORK This section provides an answer to sub-question 6: What is a suitable systems engineering framework for High Speed Craft standard projects?

In order to explain the sequence of processes and methodologies used for the development of systems, SE uses life cycle models. INCOSE (Haskins, 2006) states: "The purpose in defining the system life cycle is to establish a framework for meeting the stakeholders’ needs in an orderly and efficient manner." Some models emphasise more verification or stage gates than others, but essentially, they all contain (1) iterative design parts, (2) stage gates and (3) feedback loops:

1. Consecutive application of repetitive steps until the design goals are met. 2. Description of design status before being able to go to the next step in the design phase. 3. Verification of the initially established objectives.

Section 2.6.1 will elaborate on the different SE life cycle models. Section 2.6.2 will present the framework, and Section 2.6.3 will explain the transition of procedures.

2.6.1. LIFE CYCLE MODELS Five methods of systems engineering are investigated: the V-model, the DoD-model, the Waterfall model, the INCOSE V-model and the Kossiakoff model.

V-model Figure 2.21 represents the most commonly used life cycle model: the V-model. This model is based of the V- model from the Dutch civil handbook (Leidraadse, n.d.), but there are many variations. Some V-models have different numbers of steps along the V and/or miss the post development phase part. This figure is the most complete representation of the V-model.

Figure 2.21: V-model - Dutch Civil Handbook [Source: Irith Lely, based on Leidraadse, n.d.]

The left part of the V represents the complete development phase, including engineering. The right repre- sents the integration and testing of the components (bottom), the assembly of the subsystems (middle) and the complete system (top). The most right horizontal part represents the scheduled usage and maintenance period including scheduled updates of the vessel, ending with the demolition. The three dots in the green oval represent the definition of operational objectives, functional requirements and systems breakdown of the vessel.

The V-model emphasises on the verification (during the development) and validation (during the execution), presented by the grey arrows. The functioning of the actual components and (sub)systems are validated with the original objectives and functional descriptions, per system level. On top of that, during the design, the final description of the subsystems must be verified, to ensure whether they meet the operational objectives. These verification and validation steps can only be done when the MOEs (measure of effectiveness) and MOPs

Master’s Thesis 38 Irith Lely (measure of performances) have been defined.

DoD model The DoD model emphasises on decision points and focuses on making the correct design decisions for the vessel to be able to fulfil MOEs and MOPs. The correct definition of MOEs and MOPs is strongly emphasised, in view of the nature of their activities. They call their joint battle force the supersystem, that must be able to serve multiple objectives. The ship acts as a system within this supersystem. The fundamental engineering process of the DoD model has an iterative nature (see Figure 2.22).

(a) DoD - Fundamental Engineering Process (b) DoD Life Cycle Model

Figure 2.22: DoD Process & Model [Source: Calvano et al., 2009]

Figure 2.22 also represents the DoD life cycle model. Calvano et al. (2009) state: "At these critical decision points it must be ensured that the needs of the supersystem are properly addressed in the design and opti- mization of the system for its role in the supersystem."

Waterfall model Figure 2.23 represents the waterfall model, a former representation of SE that later evolved in the V-model. The arrows represent the iterative nature and validation. In this model, there is less emphasis on the verification and validation parts of SE, but more on the stage gates.

Figure 2.23: Waterfall Model [Source: Kossiakoff et al., 2011]

Master’s Thesis 39 Irith Lely INCOSE V-model The INCOSE-V model emphasises on presenting a complete SE standard. INCOSE (Haskins, 2006) elaborates on 24 different SE processes and continuously express all processes need to be tailored to each company and product (see Figure 2.7). Practising SE implies high costs and there are degrees in applying formal systems engineering processes (explained in Section 2.2).

Figure 2.24 represents the INCOSE model, which is a V-model as well. This model is based on previous stan- dards (see AppendixJ).

(a) Left Part of V (b) Right Part of V

Figure 2.24: INCOSE: V-model [Source: Haskins, 2006]

Kossiakoff model

Figure 2.25: SE Life Cycle [Source: Kossiakoff et al., 2011]

Figure 2.25 represents the life cycle model of Kossiakoff et al. (2011), who elaborate deeply on the SE life cycle including steps, stage gates, roles of the system engineer and give practical examples originating from different industries. According to Kossiakoff et al. (2011), this model is based on "the DoD (the acquisition management model), the International model (ISO/IEC 15288) and the National Society of Professional Engineers (NSPE)." Figure 2.26 lists the principle objectives for each stage of the life cycle.

Master’s Thesis 40 Irith Lely Figure 2.26: SE Life Cycle Explanation [Source: Kossiakoff et al., 2011]

Preferred model for Damen Damen needs a tailored SE life cycle model. Standard projects at HSC require a practically strong approach, because Damen does not want to lose their fast concept development phase to an overkill of documentation. Since the problem is not recognised by all employees, Damen needs a visually strong approach. A practically and visually strong approach avoids problems related to ineffective hand-overs. The emphasis on operational objectives and functional requirements avoids problems related to the ineffective external and internal align- ments. The model must also focus on quality control, to avoid hidden deficiencies and eventual warranties. Only when these values are met, the expected result will be higher than the intended result (see Section 2.3). Table 2.1 gives an overview of the values attributed to the five models, on the topics practically and visually strong (column P & V), emphasis on operational objectives and functional requirements (column O & F) and quality control (column QC). To illustrate the difference in the values attributed to these characteristics, the following symbols have been applied: - (least strong), 0, + and ++ (most strong).

Table 2.1: Comparison of Systems Engineering Life Cycle Models [Source: Irith Lely]

Model P&V O&F QC Total V ++ + ++ 5 DoD - ++ + 2 Waterfall 0 + 0 1 INCOSE V - ++ ++ 3 Kossiakoff ++ ++ + 5

• P & V (Practicality & Visuality) The V and the Kossiakoff models score the highest on practicality and visuality. The DoD and INCOSE V-models show an overkill in their processes (making them less strong on visuality) and the Waterfall model is based on the V-model. • O & F (Objectives & Functional requirements) All models score positive on this point, as it is a signature characteristic of SE. The DoD, INCOSE V and

Master’s Thesis 41 Irith Lely Kossiakoff models elaborate the most on the process of describing objectives and functional require- ments. • QC (Quality Control) The INCOSE V and V-models score the highest on quality control, as they strongly emphasise on the verification and validation part of the process.

The tailored framework for Damen will be based on the Kossiakoff model during the concept development phase in combination with the V-model during the execution and post development phase. These models are expected to achieve the highest result with the lowest sacrifice. The framework will also use the functional breakdown structure (FBS) and system breakdown structure (SBS) of Moredo & Krike (2010); see appendixI for a short summary of the paper. Their clear explanation of generic versions of FBS and SBS are considered a welcoming addition to create a practical and complete SE model for Damen. M. Krikke states that FBS will provide a better and more complete starting point for the designer and that the operational profiles will give insight in the intended operation of the vessel.5

2.6.2. PROPOSED FRAMEWORK This section presents the proposed framework for standard HSC projects, based on a combination of the Kos- siakoff model during the concept development phase and the V-model during the execution and post develop- ment phases (see Figure 2.27). AppendixL elaborates further on the detailed process of Kossiakoff et al. (2011).

Figure 2.27: Proposed Framework [Source: Irith Lely, based on Kossiakoffet al., 2011; Leidraadse, n.d.]

The framework presents a hierarchical structure of operational objectives and functional requirements. In principle, components are not specified during the concept design development, provided that the opera- tional objectives and functional requirements are well described and properly allocated. Components are specified during the execution phase (detail engineering), except for big components such as main shape, di- mensions and machinery.

5Interview with M. Krikke.

Master’s Thesis 42 Irith Lely Figure 2.28 shows the generic setup of operational objectives, functional requirements and the systems break- down (components).

Figure 2.28: Generic setup of systems engineering [Source: Irith Lely]

• Operational objectives (MOE, measure of effectiveness) The top row represents the overarching objective, followed by primary objectives and secondary objec- tives, or even lower levels. MOEs describe the objectives of the entire system (the vessel). Specification of objectives is appropriate until an objective is verifiable, or when one starts to define functional require- ments of (sub)systems (MOPs). • Functional requirements (MOP,measure of performances) MOPs describe the functional requirements of (sub)systems, which can also have a hierarchy. • Systems Breakdown (Components) Components are divided into main groups and are filled in during the execution phase (detail engineer- ing). During the concept development phase only the main shape and dimensions and main machinery are defined.

All sections (MOEs, MOPs and components) are allocated to each other (see Figure 2.29).

Figure 2.29: Example of allocation of sections within Systems Engineering [Source: Irith Lely]

Master’s Thesis 43 Irith Lely Operational objectives can be linked to multiple vessel systems; one system can support multiple objectives. Multiple components can serve one operational objective/functional requirement or multiple systems. How this is done is explained in Section 2.7.

Figure 2.30 illustrates the SE process for the new concept development phase of standard High Speed Craft projects.

Figure 2.30: SE Process - New Concept Development Phase [Source: Irith Lely]

• The product portfolio manager (PPM) can still work alone as long as he creates the MOEs, MOPs and their allocations and the systems breakdown structure (explained in Section 2.7). • Meetings must contain separate moments to discuss these items. • Additional meetings are required when they prove to be too short. • New is the structural designation of an internal client when there is no other client involved.

2.6.3. TRANSITIONOFPROCEDURES

This section presents a guideline to implement systems engineering (SE) in High Speed Craft standard projects; it expresses how to overcome the concerns of the current employees and it explains what areas of the frame- work need special attention in order to succeed in SE. Figure 2.31 illustrates the proposed guideline for the transition of procedures at Damen.

Master’s Thesis 44 Irith Lely Figure 2.31: Guideline - Transition of Procedures [Source: Irith Lely]

It is not recommended to change the design of an existing vessel into SE; it will not be effective and most prob- ably a waste of time. Defining operational objectives and functional requirements influences the complete design and requires a different approach from the designers. Therefore, it is recommended to start with a new standard design.

As it takes time to learn the skill of specifying operational objectives and functional requirements and allocat- ing them to components, it is recommended to choose a new standard vessel design without external client involvement (it is not clear how long and how much effort it will take to finish the first project).

It is recommended that Damen appoints an internal client to keep track of the defined operational objectives. The internal client must be involved during the execution phase (detail engineering) as well, to ensure that operational objectives are met. Having an internal client may also be a risk; designer might not take the new approach/internal client seriously.

When building a second version of this new standard vessel, operational objectives, functional requirements and components, including their allocations, can be copied. Should new clients insist on having only a list of components as contract specifications, Damen could choose to meet their request. However, it is recom- mended to also change the mindset of the new client and only use the contract specifications ’new style’.

It is also recommended to carefully choose an external client for further SE projects, who is willing to partici- pate in the transition of procedures.

Conclusion Based on the comparison of five life cycle models (V, DoD, Waterfall, INCOSE-V and Kossiakoff), the tailored framework for Damen is based on a combination of the Kossiakoff model during the concept development phase and the V-model during the execution and post development phases, also using functional and system breakdown structures.

The framework presents a hierarchical structure for operational objectives and functional requirements. In principle, components are not specified during the concept design development, provided that the opera- tional objectives and functional requirements are well described. Components are specified during the execu- tion phase (detail engineering), except for big components such as main shape, dimensions and machinery.

Master’s Thesis 45 Irith Lely Operational objectives can be linked to multiple vessel systems; one system can support multiple objectives. Multiple components can serve one operational objective/functional requirement or multiple systems.

A guideline is created to implement systems engineering (SE) in High Speed Craft standard projects; it ex- presses how to overcome concerns of the current employees, it explains what areas of the framework need special attention in order to succeed in SE and it gives specific recommendations how to introduce SE.

Based on the current information, the expected result is that the intended result of the concept development phase is met (and therefore is the same amount), presented in Figure 2.40. The height of the amount of result and amount of sacrifice is presented by a number of units (respectively circles and squares), where more units means an higher result or a larger amount of sacrifice.

Figure 2.32: SE Standards HSC - Result & Sacrifices [Source: Irith Lely]

The actual result and actual sacrifice cannot be determined until the process is executed. To estimate the expected sacrifice, one must further look into the manner of executing the framework activities. The theoretical effectiveness is now set to be 1, due to the same amount of intended and expected result.

Master’s Thesis 46 Irith Lely 2.7. COSTS This section provides an answer to sub-question 7: What are the costs of performing systems engineering at High Speed Craft?

What will it cost to identify and define operational objectives? Following questions help to identify and describe operational objectives:

• Is the operational objective clear enough and comprehensible to all parties involved? • Is the operational objective verifiable? • Would decomposition lead to better understanding? • Does the operational objective need clarification by describing its functional requirement(s)?

Figure 2.33 shows generic operational objectives for FCS projects.

Figure 2.33: Generic Operational Objectives - FCS [Source: Irith Lely, based on Kossiakoff et al., 2011]

• The overarching objective is ’Provide safe and quick transportation’. • Primary objectives specify the overarching objective, which can be further specified in secondary objec- tives, or even lower levels. • The primary objective ’Meet class requirements covers most HSEQ (Health, Safety, Environment & Qual- ity) objectives; it has two secondary objectives. • The primary objective ’Able to fulfil operational profile’ covers all objectives on the different sailing areas, loading conditions and specific vessel operations; it has six secondary objectives, each having objectives on a lower level.6 • The primary objectives ’Costs below...’ and ’Achieve delivery in ... months’ both have two secondary objectives.

In general, Damen likes to design generic platforms by copying complete systems into new designs. It also occurs, that designers want to make bold design decisions without taking the effort of research, just because these statements make a great sales pitch. The novelty of the generic operational objectives tree, is that the hierarchy allows to make ’bold statements’. The structure offers the possibility to copy the objectives when starting new projects.

6Based on Moredo & krikke (2010), the five generic types of operational modes are recognisable within the objectives tree.

Master’s Thesis 47 Irith Lely Especially for the first SE projects, the expected sacrifice will be very high. Engineers are forced to create some- thing they are not familiar with, which must be regarded as a sacrifice. It also demands a big time sacrifice to learn the skills needed to create an operational objectives tree that is correct and complete, without adding engineering solutions. The bright side is that as soon as the skills and habits are owned by the employees, the objective tree can be created through copying when designing new standards. During the concept de- velopment phase of copied standards, the operational objectives tree is only slightly altered, resulting in low sacrifice from the D & P engineer.

What will it cost to identify and define functional requirements? The definition of functional requirements is not an easy nor a straightforward process. To achieve a certain sailing range, one can e.g. either install huge fuel tanks, or make the hull very efficient. One can also make the engines extremely efficient, or implement a combination of all in the design. The fact that operational objectives often are not directly related to the functional requirements of the system(s) does not simplify the process. On top of that, interrelations between the systems on board make it even more difficult to define the functional requirements of subsystems. Replacing a system will almost certainly influence the functional requirements of many other subsystems.

Following questions help to identify and define functional requirements of (sub)systems:

• Are there operational objectives that require sensing or communications? If so, descriptions of signal input, processing, and output functions must be added. • Does the system require information to control its operation? If so, how are data generated, processed, stored, or otherwise used? • Does the system involve structures or machinery to house, support, or process materials? If so, what operations contain, support, process, or manipulate material elements? • Does the system require energy to activate, move, power, or otherwise provide necessary motion or heat? If so, descriptions of input, processing and output functions must be added.

Identifying the inputs and outputs of the system can assist the designer to identify its functions. The trans- formative functions are the most difficult to identify compared to the in and output functions, as the input is often not related one-on-one with the output (see Figure 2.34).

Figure 2.34: Function category versus functional media [Source: Kossiakoff et al., 2011]

Master’s Thesis 48 Irith Lely The terminology of a functional requirement is important, Kossiakoff et al. (2011) guide this by presenting the table in Figure 2.35 that helps to specify the input and output per class function.

Figure 2.35: System Functional Elements [Source: Kossiakoff et al. (2011)]

Using Kossiakoff’s guidelines, the input functions are mostly straightforward to describe. For sewage treatment e.g. it is clear what the inputs are.

• Signals: user commands (’flush on’ and ’off’) • Data: none • Materials: waist water, chemicals • Energy: electricity - net type • Forces: sewage weight, flow rate forces

Outputs can also be easily identified:

• Signals: status (on or off), status of tank (full or empty) • Data: none - perhaps status to bridge? • Materials: sediment sludge, grey water • Energy: heat • Forces: flow rate forces

Use the question ’How is the water and sewage transformed and placed into sewage sludge, grey water and the sewage tank?’ to specify the transformative functions. When keeping the functions at minimal and high level and using the verb-object syntax, an example of the functional description of a sewage treatment system may be:

1. Input functions: (a) Accept user command (on/off) (b) Receive chemicals (units?) (c) Receive waist water (unit of how much) (d) Distribute electricity (units ?) (e) Distribute weight (units?) 2. Transformative functions: (a) Mix waist water and chemicals (b) Facilitate removal of waist water

Master’s Thesis 49 Irith Lely (c) Facilitate drainage of sediment into tank (d) Transform level of tank to output signal (e) Facilitate filling/discharge of tank (f) Facilitate de-aeration of tank

3. Output functions:

(a) Provide status level of tank at bridge (b) Dissipate heat (c) Discharge including international connection

The process of specifying functional requirements is exploratory and iterative. Especially when the allocated objective cannot be met or should be altered in order to improve the design, lots of time can be spent on cre- ating a complete list of requirements. Ultimately, the list must not contain contradicting requirements or be incomplete. When a designer copies a functional requirement list from an existing vessel, features may be copied that are not necessarily essential to the operational behaviour of the new vessel. To significantly reduce this risk, copying must be done with great care and functional requirements must be directly allocated to their objectives.

When defining functional requirements, designers may discover incompatible operational objectives. To meet the operational objectives e.g. ’provide noise level below X DBa’ and ’achieve the challenging speed of 40 kn’, the total system may turn out be too heavy and thus produce a lower maximum speed. All the more important to combine specifications of functional requirements to system allocations with the utmost care. The func- tional requirements of the systems form a base for the contract specifications. Only big components, with large influence on the design, should be mentioned in the SE version of the contract specifications. It is es- sential to verify the functional requirements with their allocated operational objectives, to ensure the system meets the client’s needs.

The expected sacrifice will be very high the first time engineers create the functional requirements structure (higher than with the objective tree). It is complex to set up a structure how to define all ship systems, even though examples from Vries (2015) and the warship can be used as leading structure (see AppendixesE andF). The time and dedication required from employees in order to learn the skill of functional describing is a huge sacrifice and essential for the success and results of the project. Not only the skills need to be created, but also the structure of the SE contract specifications must be defined, by listing the functional requirements and main components. The list can vary per design. The time it takes to create a standard for the SE contract specifications will again be a large sacrifice. The more experienced the designer is with the process, the less the sacrifice. When skilled employees copy standard vessels, the required time to create new contract specifications is esti- mated to be only slightly higher compared to the current concept development phase.

What will it cost to create allocations? Two programs are presented, able to handle the complexity of allocations between objectives, requirements and components. The first is Shipbuilder (n.d.), a program built alongside the creation of Moredo & Krikke (2010)7, when they did research into the novelty of how their systems breakdown structure should be designed. The second is DOORS (n.d.; see Figure 2.36), a program used during the execution of the warship project. Both programs have similar characteristics, both are able to allocate between hierarchical structures. They can give a status to requirements and link documents such as HAT, FAT and SAT (Harbour, Factory and Sea Acceptance Tests) to the appropriate operational objectives and functional requirements.

7Interview with E.M. Krikke

Master’s Thesis 50 Irith Lely Figure 2.36: DOORS interface - Car Example [Source: DOORS, n.d.]

Another novelty of using such program, is when a client wishes to adjust or customise anything on a standard vessel, the allocations leading from the component to its functional requirement and operational objective (and the other way around) create extra insight in the impact of such requests. Since a project team within Damen is already familiar with Doors, it is recommended to use it. Implementa- tion of the program is an enormous sacrifice.

What will it cost to to divide the vessel into systems? After definition of the functional requirements, it is important to arrange them in logical groups, per system. The SBS of Moredo & Krikke (2010, see Figure 2.37) emphasises on bundling the generic ship systems. It can be applied to create an hierarchy for functional requirements and for the systems breakdown (components).

Figure 2.37: System Breakdown Structure [Source: Moredo & Krikke, 2010]

The way the systems breakdown structure is defined influences the creativity and quality of work the system engineer delivers. When the breakdown does not represent the systems, the engineer has to weigh out views more often and allocate the correct components to each other, which is inconvenient.

Master’s Thesis 51 Irith Lely The current Damen system codes8 are divided in similar groups, however, it is less convenient than the SBS of Moredo & Krikke (2010), showing one system at the time; see Figure 2.38.

(a) Moredo/Krikke SBS groups (b) Damen system codes

Figure 2.38: Two System Breakdown Structures

Changing the Damen System Codes would cost a sacrifice of which the scale is hard to define, since these codes are used through and through and well-known by Damen employees. The result, however, is in the benefit of the quality of performing systems engineering, for which the framework still recommends to use the Moredo & Krikke (2010) system codes. When one considers the usage of the breakdown structure of Moredo & Krikke (2010), the cost of dividing the vessel into systems is low. This depends on the innovation level of the vessel and whether systems require a new place need to be added to the structure?

What will it cost to identify and define components? When defining MOEs (measure of effectiveness) and MOPs (measure of performances), designers must weigh out the value of achieving an operational objective versus the cost of fulfilling a functional requirement (see Figure 2.39).

Figure 2.39: MOE, MOP versus Objectives and System Requirements [Source: Irith Lely, based on Calvano et al., 2009]

Chances are that with different system lay-outs or components, the same MOE will be achieved at a different rate of success. System lay-outs come at a cost, hence system lay-outs that are extremely expensive but just slightly better in achieving the MOEs, are not favourable. Defining the majority of components is done by detail engineers during the execution phase. Since they are familiar with this process, the sacrifice remains the same as in the current situation.

What are the miscellaneous costs? The number of required meetings of this new development phase is quite similar to the current situation. The content of the meetings is different though, it focuses on MOEs, MOPs and their allocations.

8Based on UNAS - the uniform administration-system developed in the early 90’s.

Master’s Thesis 52 Irith Lely Conclusion The new approach demands a lot of skills, dedication and an appropriate mindset. When practising this ap- proach for the first time, the expected sacrifice is higher than when designers are more familiar with the set-up. Applying the program Doors (or similar) requires time and effort, its implementation is an enormous sacrifice. Changing the Damen System Codes would cost a sacrifice of which the scale is hard to define. When using the breakdown structure as proposed, the expected sacrifice of dividing the vessel into systems is low. Defining the majority of components is done by detail engineers during the execution phase. Since they are familiar with this process, the sacrifice remains the same as in the current situation. The number of required meetings of this new development phase are quite similar to the current situation, therefore the sacrifice remains the same. The content of the meetings is different though, for it focuses on MOEs, MOPs and their allocations.

Once a standard vessel has been developed using this new approach, operational objectives, functional re- quirements and components can be copied to create another new standard project. This must be done with utmost care since specifications and allocations do not necessarily apply to the new standard. This demands a considerable amount of time and effort from the product portfolio manager (PPM). The more skilled the PPM, the less time and effort it takes, thus the lower the expected sacrifice.

Figure 2.40 presents the cost of the SE process of HSC standard projects (first time versus when more skilled). Separate steps are as discussed and sacrifices are summarised in the figure. The height of the amount of result and amount of sacrifice is presented by a number of units (respectively circles and squares), where more units means an higher result or a larger amount of sacrifice.

Figure 2.40: Cost Systems Engineering High Speed Craft - Results & Sacrifices [Source: Irith Lely]

The actual result and actual sacrifice cannot be determined until the process is executed. In view of the scope of this research, the expected sacrifice during the execution phase is not determined. At the first SE process, the theoretical effectiveness (R/R) is lower than 1. The theoretical productivity (R/S) is very low during the concept development phase. The efficiency (S/S) cannot be determined.

Master’s Thesis 53 Irith Lely

3 CONCLUSIONS

The overall conclusion of this master’s thesis is given by answering the research question.

In what way can systems engineering improve the effectiveness of the concept development phase of High Speed Craft standard projects?

After extended research in the theoretical background as well as extended research into the current concept development phase of standard High Speed Craft vessels, the following framework for executing systems engi- neering is recommended:

Figure 3.1: Proposed Framework [Source: Irith Lely, based on Kossiakoffet al., 2011; Leidraadse, n.d.]

The tailored framework includes a subsequent guideline, to allow Damen Shipyards to introduce systems en- gineering in the concept development phase of High Speed Craft projects.

The theoretical effectiveness of the framework is evaluated by considering the intended, expected and actual result, as well as the expected and actual sacrifice. The intended result is implicitly defined during the problem definition. The following list represents the intended result of the concept development phase of HSC standard projects:

• Proper documentation for effective external and internal alignment on the product definition. • Effective hand-over between sales management and project management. • Appropriate system definitions to enable sufficient quality control.

Figure 3.2 shows the intended result as a constant over the three different project types (current standards and SE standards HSC - first time and experienced). The height of the amount of result and amount of sacrifice is presented by a number of units (respectively circles and squares), where more units means an higher result or a larger amount of sacrifice.

Master’s Thesis 55 Irith Lely Figure 3.2: Conclusion - Results & Sacrifices [Source: Irith Lely]

The current standard project units, summarised in the table, are determined after carefully evaluating the cur- rent process. The expected result of the SE standard HSC projects, is based on the outcome of the research into different life cycle models and their results. The actual results and sacrifices of the SE projects can only be determined after executing the project.

The ratio between the intended result and the expected result is the theoretical effectiveness (R/R). Considering Figure 3.2, the theoretical effectiveness of the current standards is lower than 1.

Even though employees of High Speed Craft would expect higher results, research into the current concept development phase with its reoccurring problems indicates that executing the current process will give an ex- pected result as shown above. Both for new standards and copies standards, the theoretical effectiveness (ratio of intended and expected result) is lower than 1.

The theoretical effectiveness SE standard HSC projects, will be lower than 1, when it is executed the first time. This is due to the lower expected result of the concept development phase, the first time employees will carry out SE. The theoretical effectiveness of the concept development phase of SE standard projects, when design- ers are more skilled, is 1 and will increase more and more.

Master’s Thesis 56 Irith Lely 4 DISCUSSION

During the development of this master thesis, the following discussion points came forward.

• The board of Damen Shipyard needs to decide when the transition of procedures will take place. The suc- cess of this project demands full commitment of all parties involved. This implies changing the mindset of all Damen employees. The current strategy of Damen is to avoid misinterpretations of the contract specifications. Employees literally stated they "avoid the risk of having to meet certain requirements"; they prefer not to describe these requirements in the specifications. Changing this mentality has a great influence on the way people communicate and interact. Practising SE means to turn this risk avoiding strategy around into a customer-focused mind set. • Time registration is not sufficient enough to pinpoint the exact location of the currently experienced problems and it is not possible to calculate the exact total of (re)working hours spent on the entire project. There are two views on the current time and budget control: D & P makes a wrong estimation resulting in time and budget shortages versus the execution phase is done wrongly, resulting in time and budget shortages. The success of implementing SE also depends on an appropriate time registration. • The success of implementing SE depends on the willingness and capability of clients to participate in the transition of procedures. This is a risk Damen has to take into account.

Master’s Thesis 57 Irith Lely

5 RECOMMENDATIONS

The following recommendations are suggested:

• Implement SE for standard vessels at HSC. • Damen must be aware and willing that implementation of SE demands mentality difference of the in- volved employees. • The concept development phase is an investment from Damen which will be ultimately payed for by the client. Engineering small vessels implies SE might be too expensive to eventually get the desired profit. Further research should be done to discover whether there is a limit in vessel size above which SE will be profitable. • Elaborate research into the costs and benefits of implementing SE during the engineering and post- development phases, as this thesis merely focuses on the concept development phase. • Elaborate research into into the costs and benefits of implementing SE at other product groups and one- off projects.

Master’s Thesis 59 Irith Lely A DIFFERENT FCSVESSELS

Figure A.1: Family Vessel Types - Fast Crew Supplier [Source: Damen Shiphards]

Master’s Thesis I Irith Lely

B CNBDORGANISATIONAL CHART

Figure B.1: Organisational Chart CNBD [Source: Damen Shipyards]

Master’s Thesis III Irith Lely

C EXAMPLES PROBLEMS

This appendix gives practical examples of the reoccurring problems at Damen. The problems are caused by the ineffective external and internal alignments regarding product definition, ineffective hand-over between sales and project management and insufficient quality control. The problems have impact on the controllabil- ity, the quality and the effectiveness; the examples are grouped per topic. For confidentiality reasons, names of countries and ship types are presented anonymously; only the names of the components and systems are genuine.

Examples controllability

Loss of control during the execution phase Upon ordering compulsory deck equipment such as life saving rafts, the engineer allocates space for the rafts, including cranes to launch them. As soon as the raft and supportive equipment has been ordered, the exact details are sent to Damen to enable detail engineers to integrate the cranes into the construction of the deck and hull. When the delivery of the components are slightly different than expected, integration problems may occur. With equipment that does not need to be integrated into a bigger system (such as a complete dredge system) these differences of single components can result in complete different characteristics of the entire system. At times, the past tense is used for these examples have already taken place.

Insufficient contract specifications This example concerns the design of the dredge system, where the project manager co-operated with multi- ple subcontractors. The hydraulics subcontractor was responsible for the movement of the different systems, Damen Dredging was responsible for the dredge equipment and the electrical subcontractor was responsible for the monitor and control system of the dredger, which is operated from the bridge. The team started to copy a dredge system from a previously built dredger. It was known that multiple amendments were required for this new design. The amendments where insufficiently described in the contract specifications. The project manager therefore initiated a document "functional description of a dredge system", in co-operation with all parties involved (subcontractors, client and Damen).

Misalignment subcontractors and Damen The above project manager noticed that the subcontractors were not aligned on expectations of the function- ing of the system, nor on the responsibilities regarding the development of certain technical subsystems. A functional description was required to clarify the view on the operation of the entire system and on the func- tion and interaction of subsystems. The project manager was content with this approach and the extra docu- ment. He indicated that describing the functionalities helped to develop and better understand the product and its integration of systems. He also indicated that this document can be used for the development of other dredge systems. According to him, it is a mystery that previous engineered dredge systems were able to oper- ate, considering the many misalignments of subcontractors.

Variation To Contract (VTC) Contract specifications are signed by the client and by Damen. By signing the contract, Damen must legally meet the specified requirements. The project manager of above example had to go through the contract and create more than fifteen VTCs to finalise the project. VTCs were not necessarily all invoiced to the client, as some changes did not cost extra but were still needed to legally capture them in the VTC. A VTC is required to ensure the client’s approval of the necessary amendments to the prior contract specifications. Another example of a VTC concerns the copying of a military training vessel for a client demanding certain changes to the standard design. After having signed the adjusted contract specifications, the client discovered

Master’s Thesis V Irith Lely the changes where not to his benefit. He wanted to re-install the standard contract specifications (which would cost Damen less money). In order to register this, a signed VTC was required. Even though either party does not always have to pay extra money, such VTCs cost effort and cause delay in the process.

Misalignment client and Damen Another example concerns dredgers. They experience peak loads, as they need a lot of power during dredging compared to free sailing. During dredging, systems that need power are e.g. the dredge system, propulsion system and HVAC system. When sailing conditions are defined from -30 to +30 degrees Celsius, the HVAC sys- tems will need extreme amounts of power in both the extreme high and the low conditions. In reality, dredgers sail within normal conditions for 10 months of the year and will experience these extreme weather conditions during two months, demanding peak loads of power. To fulfil the power demand, two large generators (en- gines) are installed. The power management system defines that during dredging, both generators must be on. However, when sailing in e.g. 15 degrees Celcius, one generator is sufficient. As a result, the power man- agement system has two generators running on 20 percent load during 10 months, causing heavy pollution since they were designed for 80 percent load conditions. Nor the client, nor Damen had a clear focus on the operational objectives.

Internal misalignment Some standard patrol vessels were designed for 4 man crew in continuous working modes. However, one of the operators patrolled near harbours, which resulted in different behaviour from the crew members regarding the use of showers. The installed 200 liter boiler was not able to meet the hot water demands when they would all take a shower within 30 minutes. If this operational objective would have been adequatly specified (all crew can shower within 30 minutes) instead of just mentioning "a 200 liter boiler is installed", engineers could have properly taken this request into account. Another example of internal misalignment concerns dredgers. The problem with dredgers is the definition of the loading conditions. Every ship has a weight limitation. When a dredger lays too deep, the chances of capsizing increases. The weight is the sum of the load (usually sand or sludge) and the consumables, such as fuel and water. The weight of the load is determined by the specific weight of the dredged sludge, and the contract specifications therefore have limitations on the volumes per specific weight of the sand or sludge. Some dredgers, however, have bottom doors which can open and close via hydraulic shafts. These shafts carry the weight of the doors in longitudinal direction, the strong direction of these shafts. On the cross sectional direction of the shafts, the shear force is determined by torsion loads of the vessel plus the shear forces created by the sludge. Sludge existing of large heavy stones and water e.g. create almost no shear force on the shafts, whereas thick sand creates large shear forces on the shafts. These shafts will buckle as soon as the shear force is too high, even though the dredger carries loads within the margins determined within the contract. This ex- ample clearly shows that only specifying maximum loads without defining all different operational objectives, will result in engineering mistakes. Should the detail engineers of the shaft have known the operational ob- jectives (instead of just the average specific weights of the sludge), they would have also considered the shear forces on the shafts.

Inadequate time registration One example is a D & P engineer who removed almost completely all detailed engineering hours for a project, as it was an exact copy of a vessel build a year ago. The detail engineer indicated in a later, that even with an exact copy of a vessel, still some components (for instance those whom cannot be delivered by sub-contractors anymore) or small modifications need to be engineered. Another is a D & P engineer asking the engineer directly for the amount of engineering hours, later discovering the engineer also made a wrong estimation.

Inadequate hand-over A client sent Damen detailed contract specifications, not corresponding with the standard vessel contract specifications. In spite of the misalignment, Damen combined the two specifications into one single con- tract, which was signed by the client and by Damen. During hand-over, engineers got lost in translation and decided to build the vessel based on the standard Damen specifications. Upon delivery of the vessel, the client stated he did not receive what he defined. Damen had to do a lot of re-work at their cost, since the client re- ferred to the signed contract.

Master’s Thesis VI Irith Lely Lack of quality A client requested a turnkey project (DTC-yard). Damen was responsible for the entire execution process, in- cluding production and delivery. The signed Damen contract stated: "Ship will be built according to Damen standards", which included the quality and safety standards during the production process. However, the pro- duction process was done by a Vietnamese yard, who signed their own contract, not including the ‘Damen building standards’. When this was discovered, Damen had to put a lot of effort into making sure the correct quality and safety standards were met. Another example of lack of quality (control) concerns situations where Damen delivers a construction plan, the yard thinks certain structural lay-outs are not handy to build and they construct the vessel in a different, in their view easier, way. Yard expertises vary enormously; sometimes the yard has the best view on matters concerned and sometimes Damen engineers have more know-how. Another example concerns the situation where Damen delivers an engineered plan on specific components, but the yard decides to install left-overs, which has a negative impact on the quality of the vessel.

Late or faulty delivery of components Damen executed a program to design, manufacture and deliver 14 Tugs according to a comprehensive client specification. The client issued very detailed and demanding requirements. and the structure of client’s con- tract specification was not aligned with the standard Damen contract specifications, causing continued dis- cussion during the complete program. In the end, non-standard components where ordered, whom where individually able to operate according to the set quality standards, however could not comply with the quality as system as a whole. Damen had to spend considerable money to ensure client acceptability at delivery. Es- pecially due to the copy factor, the money loss was even higher.

Hidden deficiencies The wrong cathodic anode protection was ordered and installed, for a standard vessel build over 30 times. This caused all vessels to corrode quickly, with the major repair jobs Damen had to pay for. This could have been solved when there was more focus on the allocation between the anode and hull material, as well as verifica- tion between the systems breakdown and its objective. Especially due to the impact of the copy factor, this was a major cost for Damen.

Lack of responsibility D & P engineers have certain topics that they would rather not write down the functional descriptions. This especially is regarding the HVAC functional descriptions, regarding sailing characteristics, regarding sound limitations, etc. Further more due to the complexity of the problems, it mostly difficult to make one discipline responsible. This gives room for employees to not take responsibility or ownership of the occurring deficiencies. A often heard excuse is the catch all term "incident" versus "structural mistakes". The trend for employees within the execution phase is to label mistakes as incidents, where as employees out-side the execution phase tend to name the mistakes structural.

Examples effectiveness A client knew and agreed on the type of engines installed, but discovered during the operations that the cap- tain could not write on a piece of paper when sailing at full speed, due to the high amount of vibrations. The vessel was as such not effective in achieving the operational objectives, as the high amount of vibrations re- sulted in a non-workable situation. Another example is the situation where a client knew and agreed on installed HVAC equipment (Heating, Venti- lation and Air-Conditioning). However, in certain weather conditions the resulting humidity and temperature were not as expected. Another example is the situation where a client provided the functional description of a bilge ballast system. Normally, the contract specifications just give a general description of the system: “All watertight compart- ments are connected with pipes and valves to a bilge system. Foot valves are fitted at different suction points providing an efficient drainage of the watertight compartments. The bilge pumps will pump the bilge water overboard or to a bilge tank. Some compartments in the fore ship are connected to the bilge system with an ejector system. The bilge system is combined with a general service system for internal fire-fighting (accord- ing Class requirements) and deck washing purposes. The deck wash system can also be used for chain wash", together with specifications of the pumps, hoses and tanks. In this case, the system was 1.5 times oversized

Master’s Thesis VII Irith Lely because engineers where afraid not to be able to meet the functional requirement. This had a negative impact on the effectiveness of the vessel. Another (bigger and more) fundamental example is the situation where a harbour operator ordered 11 new tugs and during the delivery the harbour director asked: "Why did we order the tugs in this size? We already have two of your tugs operating that are two meters smaller, but they operate perfectly fine." This last example shows that the effectiveness of the smaller tug is higher, as it is able to achieve the operational objectives at lower costs.

Master’s Thesis VIII Irith Lely D NON-QUALITY COSTS

The statement made in Section 1.4 "the lower quality result in high warranty cost" is not a one to one relation- ship and nuances should be further explained. This appendix will elaborate on the quality costs by explaining the processes before the delivery of the vessel - where the product group related business units are responsible, and the processes after the delivery - where the business unit services is responsible.

Before delivery In the phase between the contract signing and delivery of a vessel, the product groups are responsible for all processes. With the way the hours are currently written, Damen is not able to measure the cost of non-quality. All the hours employees spend on a vessel are written on the yard number. The yard number is a specific num- ber of each vessel, even if the vessel is an exact copy of another these two will have unique yard numbers. If for example an engineering fault is discovered, employees of Damen will make extra hours to make up for the mistake. At the end of the project, the total amount of hours, all material and overhead costs are summed up per vessel and per business unit. To prove the amount of money lost due to non-quality, D & P engineers (design and proposal) compare the estimated hours at the start of the project with the total true worked hours. Damen measures the differences between estimated engineering hours and true worked hours, where the discussion after every project is be- tween whether the correctness of the estimation Because the hours are not specified per activity type, this does not prove what percentage of these hours is due to non-quality.

After delivery When looking at the way hours are written after the delivery of the vessel, the cost of non-quality can be es- timated, however the accuracy of this estimation is low. This estimation is done by considering a percentage of the outlaid warranty cost. How services estimates their warranty costs is firstly explained, followed by the estimation of non-quality costs.

Warranty costs Services deals with all cases after the delivery of the vessel. They are a non-profit cost centre. For every case an activity will be opened. All activities are related to a specific ship and therefore linked to its yard number. The hours and costs made by services are written upon these activities. Services considers three different types of activities, listed in Table D.1.

Table D.1: Cost Estimate Example - Per Activity Type [Source: Irith Lely]

Activity type: Fictional percentage of total activities: Fictional costs (*million): Out standing items 25% 5.5 ≈ Findings 25% 5.5 ≈ Warranty 50% 11 ≈ Total cases: 100% After sales costs 2016: 22

The first activity type is out standing items. All out standing items are items stated in the contract specifica- tions but not yet delivered or installed. Every vessel will have some out standing items. This can be as small as a cutlery set that still needs to be delivered, as well as complete systems that still need to be implemented. The second activity type is findings. When Damen employees (these can be project managers, service engi- neers, etc.) discover deficiencies they will be listed under the activity findings. The last activity type are the warranty claims. For every claim the client declares, the services department will asses the validity of the claim. When stated that the claim should be covered by the allocated warranty post,

Master’s Thesis IX Irith Lely services will handle the claim. However when stated that the claim should not be covered by the allocated war- ranty post, services will firstly contact the sales department. Sales will indicate if goodwill should be granted or not. When the client is a major buyer, or on the verge of buying more vessels, goodwill is sooner granted then smaller clients. The exact amount of goodwill is not measured, as these activities are all written down as warranty. Services estimate a percentage of 15 to 20 % of the amount of warranty activities are actually good- will activities. Unfortunately, this estimate is based upon guts feeling and experience1.

The percentages of Table D.1, regarding how often cases occur, are fictional due to confidentiality. The outlaid warranty costs in 2016 where +- 11 million euro (fictional number), slightly more than the allocated warranty costs of 10 million. The exact outlaid warranty cost cannot be given due to confidentiality but the higher outlay is shown in Figure D.1 by presenting the percentages per IDC.

Services tries to indicate the height of non-quality costs by comparing the allocated warranty post to the outlay of the true warranty costs. The allocated warranty post are determined by D & P and this is always a certain percentage of the total IDC (cost price estimation). Every ship type has its own percentage, based upon expe- rience and trial and error. Table D.1 shows the (fictional) percentage of the amount of activities registered as "warranty". Services tries to estimate the total costs by dividing the total costs by this percentage. The assumption is that all three types of activities cost on average the same. When systematically warranty activities would cost twice as much com- pared to out standing items, this method fails as estimation of true made warranty costs. Services indicate that the variety of types of out standing items, as well as findings and warranty activities is large. As they handle all activities of the complete Cluster New Build Division there are large amounts of activ- ities. Based on the law of large numbers services indicates this assumption is safe to make[? ]. 2

The result of Services estimation of the outlaid warranty costs is presented in Figure D.1, together with the initially allocated warranty costs. The costs are presented as percentages and per business unit. These per- centages are the average of all ships and types delivered by the product groups in the year 2016. A delivered vessel has a warranty of a year, which means that as soon as the year 2018 finishes, the year 2017 can be com- pared.

Figure D.1: Percentages Warranty Costs per Business Unit [Irith Lely based on Damen Shipyards]

Figure D.1 clearly shows that the business units DTC (building all vessels on not owned yards), HSC (High Speed Craft) and workboats systematically exceed the expected amount of warranty costs. This compared to O & T (Offshore and Transport), who therefore either take less risk and allocate relatively high amounts of money, or have better process and quality of their products.

1Interview with AK, Service Line Manager, Services. 2In probability theory, the law of large numbers is a theorem that describes the result of performing the same experiment a large number of times. According to the law, the average of the results obtained from a large number of trials should be close to the expected value and will tend to become closer as more trials are performed.

Master’s Thesis X Irith Lely Non-quality costs Damen uses a research of the BAM that states: "When one knows the height of the true warranty costs, the total costs of non-quality is two to three times higher"[? ]. This is visualised in Figure D.2.

Figure D.2: Visible Warranty Costs Versus Non-Visible Non-Quality Costs [source: Damen Shipyards]

The source of the original research of the BAM could not be found by the Damen employees. The statement does not consider different processes, industries and companies. It also does not consider the average effec- tiveness of the processes within ones company, because optimised processes should have less non-quality costs even though warranty costs can be the the same. This validity of this research should be doubted. However, Damen did combine the warranty costs with the iceberg theory and due to the 10 million allocated warranty costs they calculated there is an amount of 30 million euro lost to non-quality costs3. In perspec- tive: the complete Damen group (bigger than the Cluster New Build Division) 2016 held a profit of 29.2 million euro.4

Concluding: The height of non-quality costs can be estimated via combining the warranty costs and ice-berg theory. Due to the assumptions made within the calculation of the warranty costs and the validity of the iceberg theory, the resulting value of 30 million euro for the non-quality costs should be doubted. Even though the estimation of the non-quality cost is not to be trusted, the exceeding warranty cost versus the allocated warranty costs do confirm the problems indicated by the interviews (see Section 1.3). Also confirm- ing this, are the high costs services make regarding out standing items and findings.

3Interview with MdR, Manager QA&E, Quality Control 4Interview with MJ, Cost controller at Finance and control.

Master’s Thesis XI Irith Lely

E PAPER J. DE VRIES

Jan de Vries followed the Damen Leadership Development Course (II) at Nijenrode Business University in 2015. He used his experience gained at Damen Schelde, to write a paper of implementing systems engineering at Damen Schelde (Vries, 2015). The aim of the paper was to develop a commonly accepted systems engineering method for Damen Schelde, that can be implemented in all engineering groups in a later stage. The paper starts with an introduction of systems engineering (SE), followed by a brief overview of three projects and an explanation why systems engineering was proven beneficial for these projects. It concludes with a proposal of how to implement SE at Damen Schelde.

Summary Paper Damen Schelde was obliged by a client to follow the systems engineering methodology. Three vessels where built: an escape gear ship (ocean going naval support vessel), a rescue gear ship (offers extra deck space in comparison to the Escape Gear Ship, to store more mission specific containerised equipment) and a multi- role aviation training vessel (military defence training vessel). The focus shifted from delivering drawings to the customer for review and approval to system descriptions with attached drawings. Apart from from this, there was a demand for a structured meeting sequence which was registered in the contract. The findings during the engineering and built process where the following. At the start, the method was forced upon the engineers, which resulted in resistance. The engineers felt that it would merely create useless addi- tional paperwork, they did not believe that it would contribute to the overall quality of the vessel. Nevertheless, the paper presents a list of advantages discovered by the engineers after having used the system descriptions and the structured meeting sequence:

1. During the building and commissioning of the vessel, only a few discussions on the layout and design of systems were held, in contrary to previous vessels for the same client. 2. Due to focus on integration of systems in the system descriptions, the practical integration was done in a proper way, which lead to short commissioning times with less issues, compared to other complex one-off vessels. 3. Automation, control and monitoring was described in the system descriptions and therefore clear for subcontractors, avoiding discussions between subcontractors and the yard and giving especially the subcontractor sufficient input to optimise their design. 4. The systems descriptions were an excellent input for other documentation, saving man-hours to draw these up. This also resulted in proper alignment of all documents involved, which prevented errors and contradictions. 5. Especially the vessel/system operation manual was made with far less man-hours and clients are willing to pay considerable amounts for proper system manuals. This could be a serious business opportunity. 6. The method forced the engineers to consider degraded operation modes of the systems and emergency operations. This lead to easy and cheap modifications with significant increase in reliability and oper- ability. 7. The method improved the ’safety thinking’. 8. The system description is an ideal input for new specifications and tenders and provides many more clear details than regular customer specifications. By using (parts of) the system descriptions for new tender specifications and contracts, the engineering and design discussion with a new client for a new vessel will take much less time.

View of the researcher SE proofed to be a serious improvement for the overall project, resulting in a fast building process with less re-work. The output of the systems description was regarded as a valuable input for other documentation and

Master’s Thesis XIII Irith Lely processes.

After evaluating the three projects, Vries (2015) does not propose a V-model. In fact, he does not mention the model at all, which presumably indicates that he did not consider this theory. He does propose Damen Schelde to divide the SE in a general SE set-up, considering the following three major parts:

1. System description statements. 2. Design meetings with stakeholders and timing of the system description statements. 3. Drawings & calculations.

Vries (2015) proposes a standard requirements list to specify the systems descriptions. In the paper he gives an example of a list for a fresh water system. The system description contained: concept of operation (CONOPS), regulatory requirements, documentation, maker’s list, hazard and safety including several sub-chapters. Vries (2015) also proposes a series of five meetings, starting with a release of the first system description, a product design review, a confirm and a freeze design meeting (after this, detail engineering started) and a meeting prior to the test and trial phase.

The proposal of Vries (2015) is discussed via a SWOT analysis, which summarises the strengths, weaknesses, opportunities and threats of implementing his SE methodology. The strengths are summarised in an elaborate list of improvements; improved system integration, input for other documentation, better alignment of cus- tomer expectations and deliverables, less rework during the building process, clear requirement understand- ing by co-makers and suppliers, improved Risk Management, improved focus on HS & Q, improved Project Information, improved checks and balances, and consideration of and input for ILS and Life Cycle Costing. According to Vries (2015), the depends on the size and complexity of a project. For small projects there is a risk of ’overkill’ in conducting the systems description statements. Another risk is a possible lack of knowledge and expertise within the Damen group for the systems engineering methods. Projects are forced by Damen or client in view of a fast delivery, which can result in the improper execution of SE or can result in losing clients. The opportunities are that vessel and systems operation manuals are easily produced and become a new sell- ing point. Also, the availability of SE within Damen is a selling point for government-related customers. Both the products and the specification for new bids are improved. The automation part is done by engineering, a much clearer scope can be provided to subcontractors and co-makers for follow-up projects. The threats are that when SE is not properly introduced and implemented, there will be resistance from engineers. They will see SE as administrative load only. A threat is therefore not properly aligning the level of SE with the product. Damen will need a different approach per Damen company. Some customers may receive too many details which can result in industrial espionage. The last threat could be a lack of cooperation by subcontractors and co-makers.

The paper concludes that Damen Schelde will start using SE and it predicts that Damen Gorinchem (by which he means Commercial New Build Division, the official name) will experience more resistance from engineers but they would also benefit greatly from using systems engineering techniques, especially for the business unit Offshore & Transport and one off or standard vessel designs.

Master’s Thesis XIV Irith Lely F SEWARSHIPAT CNBD

The warship is CNBD (Commercial New Build Division) project. The project was run until the complete con- cept development was finished, after which the local government decided not to build the vessel with Damen. In this project, the client forced Damen Gorinchem upon a systems engineering approach, which was also the case with the three Damen Schelde projects described by Vries (2015). For the development of the warship, the V-model is used as a method to execute systems engineering. The summary of this project only considers the explanation of how requirements during the concept development phase are managed.

Brief summary Figure F.1 shows the warship requirements management overview, how all the different lists of system require- ments are linked via matrices. The terms used for the documents are project-specific systems engineering terms, determined by the local government. All requirements were managed in the software application DOORS (n.d.). The project started with receiving the Preliminary Operation and Support Intent (POSI) and Statement of Work (SOW), developed by the local government. The documents indicate the ins and outs of the operational behaviour of the vessel (described in POSI), together with the expectations of the government on Damen’s project deliveries (described in SOW). Damen translated these two documents into the Functional Performance Specification (FPS).

Figure F.1: Requirements Management Links [Source: Vries, 2015; DOORS, n.d.]

The three boxes in the left column result in a list of functional descriptions of the entire ship in different op- erational modes: how, where and how long, will the ship be used? This Functional Performance Specification is a hierarchical structure and can be compared to the Functional Breakdown Structure (FBS) as described by Moredo & Krikke (2010), see sectionI. The middle column represents the (hierarchical) system descriptions per (sub)system, starting with the complete ship as one system and ending with the functional description of the subsystems and components. The System Specification (SS) is also a layered structure and can be compared to the System Breakdown Structure (SBS) as described by Moredo & Krikke (2010). The Integrated Support Plan and Support System Specification define the ILS (Integrated Logistics Support) of this project. ILS considers the management of the ship after delivery. The Integrated Support Plan (ISP) contains information of the pro- cesses of services, the Support System Specification (SSSPEC) contains information of the support systems, such as spare parts and crew training. The right column represents the right side of the V-model; it determines how the components and systems will be validated. The Inspection & Test Plan (ITP) represents the testing ac- cording to class, the Acceptance Test Procedure and Report (ATProc and ATRep) represent the testing in order for the client to accept the functionalities of the ship before delivery.

Master’s Thesis XV Irith Lely View of the researcher An interesting fact is that the System Specification (SS) for this project is based on one of the ships built at Damen Schelde: the multi-aviation training vessel described by Vries (2015), see sectionE. Damen Gorinchem indicated that the other two ships described in Vries (2015) were less developed in describing the systems specification compared to the MATV. Furthermore, the link between the functional description to the differ- ent systems installed on board, is not a one-on-one relationship. Functional requirements (e.g. ship speed) are linked to multiple systems. Also, a system can contribute to multiple functional requirements. Like with Moredo & Krikke (2010), a matrix links the FPS to the SS and for the warship this matrix is called the Require- ments Traceability Matrix (RTM). Moredo & Krikke (2010) follow a similar structure as the warship. The systems description statements described by Vries (2015) is less similar; they combine both the FPS and SS (warship) or the FBS and SBS (Moredo & Krikke, 2010).

Since the warship project has not been fully carried out, this set-up of the requirements management has not been proven through execution of the project, it has only been validated by experienced senior engineers.

Master’s Thesis XVI Irith Lely G V&V

The workstream Verification & Validation (V & V) evolved from the Organisational Value Analysis (OVA, see section 2.2). The V & V project focuses on implementing the V-model (starting in 2018 and ending in 2021) at CNBD (Commercial New Build Division). Figure G.1 shows the current situation, the changes and goals defined by Damen.

Figure G.1: V & V goals [Source: Damen Shipyards]

Grosso modo, this project is carried out to increase the quality and to decrease the amount of time and costs.

Figures G.2, G.3 and G.4 elaborate on the reason, the method and the instruments of the V & V workstream project.

Figure G.2: V & V - Why [Source: Damen Shipyards]

Master’s Thesis XVII Irith Lely Figure G.3: V & V - How [Source: Damen Shipyards]

Figure G.4: V & V - What [Source: Damen Shiphards]

View of the researcher The V & V project assumes the V-model is the best life cycle model for applying systems engineering, and has the goal to implement this model for the complete Commercial New Build Division. This thesis questions this model and narrows the scope towards only the business unit High Speed Craft. This thesis can therefore add value for the V & V project.

Master’s Thesis XVIII Irith Lely H

INCOSE HANDBOOK

INCOSE stands for International Council on Systems Engineering. Their handbook is consistent with ISO/IEC 15288 (ISO, 2002) – Systems engineering – System life cycle processes. ISO/IEC 15288 is an international standard that is a generic process description, whereas the handbook further elaborates on the required processes and activities to execute systems engineering processes (Haskins, 2006). ISO/IEC 15288 identifies four process groups to support systems engineering. Each of these process groups forms the subject of a chapter of the INCOSE handbook (Haskins, 2006). These processes are summarised in Figure H.1.

Figure H.1: System life cycle processes overview per ISO/IEC 15288 [Source: ISO, 2002]

INCOSE (Haskins, 2006) warns that not every process will be applied universally and that careful selection is recommended. They dedicate a chapter to the tailoring process, explaining its activities, inputs and outputs. Figure H.2 reflects the context diagram of the tailoring process.

Master’s Thesis XIX Irith Lely Figure H.2: Tailoring Process Context Diagram [Source: Haskins, 2006]

Haskins (2006) gives the following example: "A senior systems engineer at a major US company visited all of the divisions with the goal of increasing the use of good system engineering practices. His message included all the things that SE can/should do in commercial- ising products. His message also included a strong bias towards planning and documentation. Over a period of months he visited with Division Managers, Chief Engineers, Program Managers and Senior Engineers. He re- turned completely depleted of his enthusiasm. The problem was that the message was totally rejected because it either looked like useless work or way beyond anything they could afford to do from a time and dollars perspec- tive. Some time later another senior systems engineer visited many of the same people with the same purpose but a different message. The message this engineer delivered was that big gains could be made by focusing on the most important customer needs and using a select group of synergistic system engineering tools/practices. This time the message was well received."

Life Cycle Stages ISO/IEC 15288 (ISO, 2002) states: “6.2 - A life cycle model that is composed of stages shall be established. The life cycle model comprises one or more stage models, as needed. It is assembled as a sequence of stages that may overlap and/or iterate, as appropriate for the scope, magnitude, and complexity, changing needs and opportunities.” Figure H.3 reflects the life cycle stages identified by INCOSE (Haskins, 2006).

Figure H.3: Tailoring Process Context Diagram [Source: Haskins, 2006]

Master’s Thesis XX Irith Lely I MOREDO/KRIKKE

Elena Moredo worked as a researcher at the Delft University of Technology during this research. Together with Marnix Krikke, Deputy Director of the Shipbuilding Association, she worked on a research called An approach to improve the tender process in shipbuilding. This paper (Moredo & Krikke, 2010) indicates that systems engineering will serve as a solution for the problematic tender process.

The researcher had a meeting with Marnix Krikke (Feb 2, 2018). He gave extra background on the research, elaborated on the working of FBS (Functional Breakdown Structure) and SBS (System Breakdown Structure) worked and explained until which stadium they executed the trial projects.

Brief summary The goal of the research (Moredo & Krikke, 2010) is to improve the tender process and the co-operation be- tween shipyard and system integrator in commercial an naval shipbuilding. The focus of this improvement lies on documentation & communication between yard and system integrator, structured documentation of de- sign data and mapping requirements of client. The three issues are tackled by implementation of one generic approach: systems engineering. The paper gives a good insight into the tender process without systems engi- neering and the difficulties of the complexity of the systems in combination with the complexity of different disciplines and subcontractors. Moredo & Krikke (2010) argue that literature describes the use of SE for naval vessels and many sources state that the SE approach also can be used for commercial vessels. They further state that examples have not yet been given and that the main difference between naval and commercial ves- sels is the amount of system specifications done together with the amount of time a ship builder gets in order to further develop the design. Compared to commercial vessels, naval ships have a great level of detail when a conceptual design is discussed with a shipbuilder; there is a high client involved throughout the entire de- sign process. Also, commercial vessels demand a short period of time to produce a concept design. However, Moredo & Krikke (2010) still conclude SE is applicable for commercial vessels. The approach used is a combination of a generic FBS, a generic SBS and a model or matrix to convert functions to systems. Moredo & Krikke (2010) argue that FBS is able to serve as a checklist, provided that all require- ments are properly documented in the contract phase and all functions have been defined. This structures the conversations with the client ant helps the client to think constructively about his requirements. A clear, consistent and generic SBS forms a perfect basis for a documentation and communication structure. SBS can be expanded to the required level of detail of the design at that point, ultimately it continues in a Component Breakdown Structure (CBS). The functions as described in a FBS are converted to a SBS. During this conver- sion, it is important to ensure that every single function or systems is properly described and that systems included in the SBS do not serve any (sub)function. Since many requirements and functions are in one way or another linked or cross-related, a conversion model or matrix is required. This model ensures that systems and functions are traceable and therefore will not be forgotten.

Master’s Thesis XXI Irith Lely View of the researcher The novelty of this paper is the use of generic structures and the use of systems engineering for all types of commercial and naval vessels. Figure I.1 shows the recommended FBS and SBS. Moredo & Krikke (2010) use five generic types of operational modes, which have to be described:

1. loading & offloading 2. manoeuvring 3. mobilisation 4. operation 5. transit

(a) Functional Breakdown Structure (b) System Breakdown Structure

Figure I.1: FBS & SBS [Source: Moredo & Krikke, 2010]

Moredo & Krikke (2010) created 9 main system groups instead of the Damen system codes, see I.1a.

During the creation of the framework used in this thesis, the functional breakdown structure of Moredo (2010) is tried. When using this breakdown, ideally, the top three boxes are defined by client (user) and Damen (ex- pert) together. When this functional breakdown structure was used to create a FCS (as a prove of concept), there is discovered that the terminology was experienced as confusing. Therefore the following changes in definitions where made in order to ease the conversations with the Damen employees:

• Processes changed for Operational modes: Definition: A short description of the functions and activ- ities to reach the mission(s). When talking about other technical complex designs, a process would be a good term to describe the activities for reaching a goal. However, the processes of a ship are all more or less captured in 5 generic processes, which are in fact called operational modes in the shipbuilding industry. • Operational functions changed for Ship functions: A mission is sometimes called an operation, and also ‘een operatie’ in Dutch, therefor this is a confusing term. The term is probably chosen because these are the primary functions needed during an operation. However as the operational functions are describing the functions of a ship, the term ‘ship functions’ is better recognisable for the engineers with no SE background.

Master’s Thesis XXII Irith Lely J LISTOF SE STANDARDS

List of SE standards MIL-STD-499B: Although this military standard is no longer in force, it is still used as a guide by many organi- sations and it formes the foundation for understanding the basics of current system engineering processes. It consists of four basic steps: requirements analysis, functional analysis/allocation, synthesis and systems anal- ysis and control.

IEEE-1220: Commercial standard. This process could be considered as an expansion of the military standard, with a verification or validation step in between.

EIA-STD-632: Commercial standard. 13 processes are categorised into five sets: technical management, ac- quisition and supply, system design, product realisation and technical evaluation.

ISO-IEC-IEEE-STD-15288: Commercial standard. This standard presents processes for both the system life cycle and the system engineering activities.

These standards are in order of convergence level with the life cycle model of system development. In other words, MIL-STD-499B is the most divergent from the life cycle model whereas the ISO-IEC-IEEE-STD-15288 could easily be considered as a life cycle model for system development.

Master’s Thesis XXIII Irith Lely

K DESIGN CRITERIA SMALL FCS

This chapter elaborates on the document ’Design criteria of small FCS’. For confidentiality reasons, some of the data have been blurred. The document was studied with SE in mind. In overall, the design criteria are a mixture of operational objectives, functional requirements and system descriptions or solutions for the func- tional requirements. To make these design criteria ’functional’, questions should be asked such as: ’how large’, ’why is this a criteria’ or ’why has a certain system been chosen’. To illustrate this, annotations were made on the first two pages of the document.

Figure K.1: Design criteria FCS - first part page 1 [Source: Damen Shipyards]

1. Use of the term ’etc.’ is not specific enough, a complete list should be given (e.g. there is no mention of the type of fenders). 2. Large is not measurable. How large is large, when is it large enough? This criterion originated from the desire to increase sailing characteristics (mostly expressed in horizontal acceleration). The smaller FCS could still sail with a maximum of 1.5 m significant wave height; the operators wanted to increase this

Master’s Thesis XXV Irith Lely to at least 2 m. The document later specifies an increase of 500 mm, but in the final design an increase of 900 mm was executed to ensure enough clearance for optimal sailing characteristics. The objective: ’no slamming during sailing with a significant wave height of 2 m’ entails the functional requirement: ’increase of wet deck clearance over the whole length of the vessel so that the objective can be met’. 3. These two characteristics are two ’favourable design features’. They should be separated criteria, in order to be allocated to the correct operational objectives and systems. 4. The term ’special’ implies that the functional requirement ’industrial personnel should have the most possible comfort’ is very important; throughout the process all designers and engineers should try to increase this comfort. When creating a hierarchy in the design criteria this would have been obvious. The term ’special personnel’ is based on the terminology of class societies. ’Passengers’ would imply that only 12 people can be taken on board or they would have to follow the passenger ship rules, taking into account many safety measures as old people and young babies should be able to leave the vessel safely. In this case, personnel are trained offshore technicians. Legal rules are currently drawn up to correct this situation for the small FCS. 5. Should be listed per lesson learned, the term ’etc.’ should be avoided. 6. This is a functional description linked to the objectives written in the mission description and opera- tional profiles. 7. These are possible operational objectives.

Figure K.2: Design criteria FCS - second part page 1 [Source: Damen Shipyards]

8. These estimated dimensions are a result of the first iteration of the design process, in order to fulfil the desired range, top speed, capacity and functionalities. Spoiler alert: they have all become approx. 7% bigger except the draught (5% smaller). It is of great importance to adequately estimate dimensions, as the capacity of things that can be taken on board is expressed in weight and as such expressed in volume of the hull. Next to capacity, the speed, range and sailing characteristics are strongly related to hull shape and dimensions. 9. Why should the gap be X meters? This is already explained in point 2, and the distance given is already an engineering solution. 10. These two lay-out characteristics are chosen as a result from the functional requirement ’comfort of the passengers/ functional personnel’. 11. When is the crew accommodation ’large’ enough? The designer indicates that with the knowledge of SE he would have written ’Crew accommodation must comply at minimum with MLC, if possible bigger, to increase comfort’. 12. The types of cargo mentioned are a summary of questionnaires with operators. Therefore, the large level

Master’s Thesis XXVI Irith Lely fore deck and types of lashing points are a result of the desire to comply with the operational objectives and mission profile. Engineers should not have to worry about these design requirements; they should be captured in the lay-out and general arrangement. 13. Why ’reduced numbers’? Quantify ’reduced’. The middle east has a different operational profile, as they work with a much higher number of personnel (up to 50) on their platforms, which they like to transfer simultaneously.

Figure K.3: Design criteria FCS - first part page 2 [Source: Damen Shipyards]

14. The capacities (on the right) are a first estimate to comply with the functional requirements. These requirements are a result of the mission profiles of the interviewed companies. Spoiler alert: the fuel was increased by almost 20%, fresh water by 10%, the sewage and dirt oil/ bilge water remained the same. The increase of the fuel capacity can be traced back to the increase of size, which results in a bigger hull volume and is therefore strongly related to the fuel consumption. 15. How is ’comfort’ functionally described? This document now gives a list of solutions for the subsystems (hull, lay-out, structure). The MLC compliant is a defined minimum already discussed at point 11 of the first page.

16. The designer did not want to write down the maximum noise (frequent situation at Offshore & Trans- port), because in general, small vessels have a higher level of noise (which is expressed in DBa, a unit that is tested on humans when a noise is annoying or unbearable; this is proven to be combination of the frequency together with the intensity). For big vessels these descriptions are functionally expressed (per room the max amount of DBa). The designer did not dare to write a maximum limit exceeding the standard maximums for bigger vessels, as he expected that the strict maximums were probably not fea- sible. This document now only states a list of solutions for the noise reduction. What is not clear, is the decision to implement floating floors instead of a flexible deck house (common for the smaller FCS).

Master’s Thesis XXVII Irith Lely Figure K.4: Design criteria FCS - second part page 2 [Source: Damen Shipyards]

17. The vertical centre of gravity (VCG) is defined by class and influences the stability and roll character- istics. The designer gives no requirement, since the catamaran does not come close to the minimum requirements. The longitudinal centre of gravity (LCG) has influence on the trim of the vessel, which is related to the sailing characteristics and speed. The requirement is to have control over the LCG, and changing the positions of the items on the list indicates how the LCG and VCG can be influenced. 18. The maximum deadweight is restricted by the maximum load the hull can carry without getting to deep in the water. The maximum load exists of deadweight plus lightweight (not mentioned). 19. Range, speed and sailing area should be defined by links with operational objectives. 20. Refers again towards the desired sailing characteristics. 21. The class notation is rather logical considering the standard of Damen, previous experience with class and the type of vessel.

Master’s Thesis XXVIII Irith Lely Master’s Thesis XXIX Irith Lely Master’s Thesis XXX Irith Lely Master’s Thesis XXXI Irith Lely Master’s Thesis XXXII Irith Lely Master’s Thesis XXXIII Irith Lely

L STEPS KOSSIAKOFF LIFE CYCLE MODEL

This thesis focuses on the concept development phase. Figure L.1 shows how Kossiakoff et al. (2011) present the concept development phase.

Figure L.1: Concept Development Phases of a System Life Cycle [Source: Kossiakoff et al., 2011]

Every step, the functional requirements and its systems breakdown are further completed (see Figure L.2). This section further elaborates on this process, by elaborating on how the operational objectives, functional requirements and systems breakdown must be created.

Figure L.2: Systems Breakdown [Source: Kossiakoff et al., 2011]

Master’s Thesis XXXV Irith Lely Kossiakoff et al. (2011) elaborate on every sub-step of the three steps needs analysis, concept exploration and concept definition (see Figures L.3, L.4 and L.5).

Figure L.3: Needs Analysis [Source: Kossiakoff et al., 2011]

Figure L.4: Concept Exploration [Source: Kossiakoff et al., 2011]

Master’s Thesis XXXVI Irith Lely Figure L.5: Concept Definition [Source: Kossiakoff et al., 2011]

The description this thesis uses operational objectives breakdown and functional requirements based on the Kossiakoff life cycle model.

Master’s Thesis XXXVII Irith Lely

M ACRONYMS &ABBREVIATIONS

BU Business Unit C & O XL Crew & Offshore XL CE Concurrent Engineering CNBD Commercial New Build Division D & P Design & Proposal DoD Department of Defence (U.S.) DSNS Damen Schelde Naval Shipbuilding DSM Design Structure Matrix DTC Damen Technical Cooperation ETO Engineering To Order FAT Factory Acceptance Tests FBS Functional Breakdown Structure FCS Fast Crew Supplier GA General Arrangement HAT Harbour Acceptance Tests HSC High Speed Craft HSEQ Health, Safety, Environment & Quality HVAC Heating Ventilation and Air-Conditioning IDC Integral Direct Cost IFS Industrial and Financial Systems ILS Integrated Life cycle Support INCOSE International Council on Systems Engineering LCG Longitudinal Centre of Gravity MOE Measure Of Effectiveness NSPE National Society of Professional Engineers O & T Offshore and Transport OPV Offshore Patrol Vessel OSV Offshore Support Vessel OVA Organisational Value Analysis PBD Point-Based Design PM Project Management PPM Product Portfolio Manager SBD Set-Based Design SAT Sea Acceptance Tests SBS System Breakdown Structure SE Systems Engineering SR & C Ship Repair & Conversion V & V Verification & Validation VCG Vertical Centre of Gravity VTC Variation To Contract

Master’s Thesis XXXIX Irith Lely

N BIBLIOGRAPHY

Andrews, D.J. (1998). A comprehensive methodology for the design of ships (and other complex systems). DOI: 10.1098/rspa.1998.0154.

Bennet, J. G. & Lamb, T. (1996). Concurrent Engineering: Application and Implementation for U.S. Shipbuild- ing. Journal of Ship Production, 12(2), pp. 107-125.

Boothroyd, G., Dewhurst, P. & Knight, W. (2002, 2nd edition). Product design for manufacture and assembly. USA, New York: Marcel Dekker, Inc.

Britannica. (n.d.). Law of large numbers. Retrieved Nov 13, 2018, from https://www.britannica.com/ science/probability-theory/An-alternative-interpretation-of-probability#ref407414

Bruinessen, T. van, Hopman, J. & Smulders, F. (2013). Towards a Different view on Ship Design: The Devel- opment of Ships Observed Through a Social-Technological Perspective. Proceedings of ASME 2013 32nd International Conference on Ocean, Offshore and Arctic Engineering, Nantes, France.

Calvano, C.N., Jons, O. & Keane, R. (2009). Systems Engineering in Naval Ship Design. Naval Engineers Journal, 112 (4), pp. 45-47.

Damen. (n.d.). A Vessel for Every Purpose. Retrieved Oct 18, 2018, from https://products.damen.com/en

DeNucci, T.W. (2012). Capturing Design: Improving Conceptual Ship Design Through the Capture of Design Rationale (PhD Thesis). Delft University of Technology, Delft, The Netherlands.

DOORS. (n.d.). DoorScope: a free Rational® DOORS® viewer. Retrieved Oct 24, 2018, from https://www. prlog.org/11849422-doorscope-free-rational-doors-viewer.html

DTC. (n.d.). DTC – Think global, Act local. Retrieved Oct 18, 2018, from https://www.damen.com/en/services/ local-construction/dtc-think-global-act-local

Erikstad, S.O. & Levander, K. (2012). System Based Design of Offshore Support Vessels. Proceedings of IMDC12 International Marine Design Conference, Glasgow, Scotland.

Erikstad, S.O. & Rehn, C. F.(2015, volume 2). Handling Uncertainty in Marine Systems Design-State-of-the-Art and Need for Research. Proceedings 12th International Marine Design Conference, Tokyo, Japan.

Evans, J.H. (1959). Basic Design Concepts. Naval Engineers Journal, 71 (4), pp. 671-678.

Gaspar, H.M., Ross, A.M., Rhodes, D.H. & Erikstad, S.O. (2012). Handling Complexity Aspects in Conceptual Ship Design. Proceedings of IMDC12 International Marine Design Conference, Glasgow, Scotland.

Haskins, C. (2006, version 3), Systems engineering handbook; A Guide for System Life Cycle Processes and Activ- ities. INCOSE-TP-2003-002-03.

INCOSE. (n.d.), International Council on Systems Engineering. Retrieved Jan 21, 2018, from https://www. incose.org/systems-engineering

Master’s Thesis XLI Irith Lely Kana, A.A. (2016). Design of complex specials. Unpublished internal presentation, Delft University of Technol- ogy, Delft, The Netherlands.

Killaars, T. Bruinessen, T.M. van & Hopman, J.J. (2015, volume 3). Applying network science to control the interactions between ship-elements in ship design. Proceedings of the 12th International Marine Design Conference 2015, Tokyo, Japan.

Kossiakoff, A., Sweet, W.N., Seymour, S.J. & Biemer, S.M. (2011, 2nd edition). Systems Engineering Principles and Practice. USA, Hoboken Jersey Hoboken: John Wiley & Sons, Inc.

Leidraadse. (n.d.). All publications. Retrieved Jan 23, 2018, from https://www.leidraadse.nl/downloads

Levander, K. (1991). System Based Passenger Ship Design. Proceedings of IMDC91 International Marine Design Conference, Kobe, Japan.

McKenney, T.A. (2013). An Early-Stage Set-Based Design Reduction Decision Support Framework Utilizing De- sign Space Mapping and a Graph Theoretic Markov Decision Process Formulation (Dissertation). Univer- sity of Michigan, Michigan, USA.

Moredo, E. & Krikke, E.M. (2010). An Approach To Improve The Tender Process in Shipbuilding; Systems Engi- neering in Ship and Offshore Design. Proceedings of the International Conference on Systems Engineering in Ship & Offshore Design 2010, Bath, United Kingdom.

NASA. (2007, Rev 1). NASA Systems Engineering Handbook. Retrieved Oct 18, 2018, from https://www.nasa. gov/sites/default/files/atoms/files/nasa_systems_engineering_handbook.pdf

Nieuwenhuis, J.J. (2013). Evaluation the Appropriateness of Product Platforms in Engineered to Order Ships (Dissertation). Delft University of Technology, Delft, The Netherlands.

Oers, B.J. van (2011). A Packing Approach for the Early Stage Design of Service Vessels (Dissertation). Delft University of Technology, Delft, The Netherlands. Papanikolaou, A. (2014). Ship Design; Methodologies of Preliminary Design. The Netherlands, Dordrecht: Springer Science and Business Media.

Rawson, K.J. & Tupper, E.C. (2001, 5th edition). Basic ship theory. United Kingdom, Oxford: Butterworth Heinemann.

Shields, C.P.F.,Knight, J.K. & Singer, D.J. (2016). The design process as a complex system. Proceedings of ASNE Day, Arlington (VA), USA.

Shipbuilder. (n.d.). From Martime Data Noose to Data Intelligence - This is how you do it. Retrieved Nov 20, 2018, from goo.gl/LmTqEv

Veeke, H.P.M., Lodewijks, G. & Ottjes, J.A. (2008). The Delft Systems Approach; Analysis and Design of Industrial Systems. United Kingdom, London: Springer-Verlag London Ltd.

Veldhuizen, W. (2017). PID Verification and Validation. Unpublished internal presentation, Damen Shipyards, Gorinchem, The Netherlands.

Vries, J. de. (2015). A pragmatic approach for structural engineering improvement; Damen Leadership Develop- ment Course 2. Unpublished presentation, Nyenrode Business University, Breukelen, The Netherlands.

Watson, D.G.M. (1998). Practical Ship Design. United Kingdom, Kidlington (Oxford): Elseviers Science Ltd.

Master’s Thesis XLII Irith Lely