Fast-Track Innovation and Commercialization: Tools and Techniques 3031303741, 9783031303746

Citation preview

Biplab Kumar Datta

Fast-Track Innovation and Commercialization: Tools and Techniques

Fast-Track Innovation and Commercialization: Tools and Techniques

Biplab Kumar Datta

Fast-Track Innovation and Commercialization: Tools and Techniques

Biplab Kumar Datta NILU–Climate and Environmental Research Institute Kjeller, Norway

ISBN 978-3-031-30374-6 ISBN 978-3-031-30375-3 (eBook) https://doi.org/10.1007/978-3-031-30375-3 © The Editor(s) (if applicable) and The Author(s), under exclusive license to Springer Nature Switzerland AG 2023 This work is subject to copyright. All rights are solely and exclusively licensed by the Publisher, whether the whole or part of the material is concerned, specifically the rights of reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use. The publisher, the authors, and the editors are safe to assume that the advice and information in this book are believed to be true and accurate at the date of publication. Neither the publisher nor the authors or the editors give a warranty, expressed or implied, with respect to the material contained herein or for any errors or omissions that may have been made. The publisher remains neutral with regard to jurisdictional claims in published maps and institutional affiliations. This Springer imprint is published by the registered company Springer Nature Switzerland AG The registered company address is: Gewerbestrasse 11, 6330 Cham, Switzerland

Preface

The author of this book has been involved for many years, in developing new technology for the industry both in India and in Norway. The author had a unique opportunity to work with multidiscipline technology development projects at TelTek (Now SINTEF) and Kongsberg Devotek (now SEMCON Norway). Kongsberg Devotek was a part of Centre of Expertise (CoE) in Systems Engineering in Norway. At Kongsberg, the author has learnt quite a few valuable techniques for achieving efficient management of innovative technology development projects. During this period, the author has managed several fast track multidiscipline technology development (often with revolutionary technology) projects for the oil and seismic sectors industries (for customers like Statoil (Equinor), Hydro Oil and Gas, Fugro etc.), which has resulted in several patents also. The author had the privilege of leading a few game-changing technology development projects related to subsea electrification in Norway for the oil industry and automatization for the seismic industry. Autonomous snow plow machine (now commercially available in Norway) started as a student project developing the concept at Kongsberg Devotek. Kjeller, Norway

Biplab Kumar Datta

Acknowledgements This book would not have been possible without the constant support and inspiration of my beloved wife Urmila. I am indebted to my old colleagues and friends, who spared their valuable time to read, comment, and discuss the content of the books. Their valuable suggestions are worth a lot, and it has helped improve the quality of the book as well. My special thanks go to my friend and discussion partner Prof. Arild Saasen. I must also thank my old colleagues Gunnar Holms and Tormod Holmslet for their valuable comments.

v

Introduction

Innovation is vital to competitiveness in the global economy. Innovation is “the lifeblood of our global economy and the strategic priority for virtually every CEO around the world” [1]. A survey conducted by McKinsey [2] of large firms shows that innovators who are first to introduce new products and services to the market experience significantly higher revenue growth. The role of innovation as a key driver of economic growth has been confirmed by multiple studies [3, 4]. In today’s world of fast-paced innovation happening at all corners of the world, technology is getting obsolete much faster than it was 50 years back. To match the fast-evolving market demand and evolution of technology, one needs to innovate much faster than before. The whole process of developing technology/product/services from concept phase to prototyping to series production and commercialization has to happen in a very structured way so that the process is not only fast track and lean but also results in optimal solutions. This book discusses the definition of innovation and invention, classification of innovation, innovation ecosystem in a company to succeed in innovation, need for innovation and timing with respect to product life cycle, development of innovation strategy and getting ready for product development, value creation, pricing strategy, communication, Red Ocean versus Blue Ocean strategy, and management of innovation process from concept phase to commercialization along with some practical tools and techniques for achieving success in complex technology development projects on a fast track. Finally, it also addresses some challenges relevant for start-ups. The author has also presented a well-tested methodology—‘Systems engineering best practices’ that he has successfully used in managing complex multidiscipline projects. The pitfalls and issues to remember, including IP management, are also discussed. This book will be very useful for engineers/managers getting ready to take up innovation as their career. The tools and techniques presented in this book will also be very useful for people (including start-ups) involved in technology development and commercialization.

vii

viii

Introduction

References 1. Dyer J, Gregersen H, Christensen CM, The innovator’s DNA: mastering the five skills of disruptive innovators. Harvard Business Review Press, Boston, Massachusetts. ISBN 978-14221-3481-8 (hardback) 2. Bughin J, Windhagen E, Smit S, Mischke J, Sjatil PE, Gürich B (2019) Innovation in Europe— changing the game to regain a competitive edge. McKinsey Global Institute, s.l. 3. Bottazzi L, Peri G (2003) Innovation and spillovers in regions: evidence from European patent data. Europ Econ Rev 47(4):687–710 4. Coad A, Segarra A, Teruel M (2016) Innovation and firm growth: does firm age play a role? Res Pol 45(2):387–400

Contents

1 Innovation and Innovation Ecosystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Innovation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.1 Defining Innovation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.2 Defining Invention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.3 Sustainable Innovation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.4 Driving Force Behind Innovation . . . . . . . . . . . . . . . . . . . . . . . 1.1.5 Classification of Innovation Activities . . . . . . . . . . . . . . . . . . . 1.1.6 Accidental Innovation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Innovation Ecosystem in Corporate World . . . . . . . . . . . . . . . . . . . . . 1.2.1 Creating Strategic Innovation Agenda . . . . . . . . . . . . . . . . . . . 1.3 Innovation Ecosystem for Start-Ups . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.1 Funding and Valuation of a Start-Up . . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 2 2 4 4 6 7 11 12 14 15 17 19

2 Strategic Technology Development Process . . . . . . . . . . . . . . . . . . . . . . . 2.1 Red Ocean Versus Blue Ocean Strategy . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Value Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Product Life Cycle and Importance of Innovation Management . . . 2.4 Pricing Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5 Communication of Value Proposition . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6 Technology Strategy and Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6.1 Creating Technology Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . 2.6.2 Defining the Problem/Challenge . . . . . . . . . . . . . . . . . . . . . . . . 2.6.3 Disclosure of Invention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6.4 Intellectual Property (IP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6.5 Patenting Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6.6 Patenting or Keeping Innovation Secret . . . . . . . . . . . . . . . . . 2.6.7 Non-disclosure Agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6.8 Market/IPR Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6.9 Time to Market . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.7 Business Model and Business Model Canvas (BMC) . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21 22 23 25 27 28 30 30 32 33 33 35 36 37 38 39 39 43 ix

x

Contents

3 Managing Technology Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Technology Readiness Level (TRL) . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Customer Acceptance Level (CAL) . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Managing Creative People . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Why a Process is Needed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5 Concurrent Engineering and Its Benefits . . . . . . . . . . . . . . . . . . . . . . . 3.6 Industrializing Innovation Process—Chinese Way [8] . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45 45 46 46 48 49 49 51

4 Systems Engineering Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Systems Engineering Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 The Development Process and System Requirements . . . . . . . . . . . . 4.2.1 Concept Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.2 Function Means Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.3 Process of Creating Systems Requirement Document . . . . . . 4.2.4 Requirements Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.5 Types of Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.6 System Requirements Document . . . . . . . . . . . . . . . . . . . . . . . 4.2.7 Requirements Verification Matrix . . . . . . . . . . . . . . . . . . . . . . 4.2.8 System Design Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Technology Development Using Systems Engineering Process . . . . 4.4 Impact of Systems Engineering on Quality and Schedule—A Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53 53 55 57 58 63 64 64 66 68 68 71

5 Systems Engineering Best Practice and Useful Tools . . . . . . . . . . . . . . . 5.1 Systems Engineering Best Practice . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.1 Qualification of New Technology . . . . . . . . . . . . . . . . . . . . . . . 5.1.2 Decision Making Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Risk Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Fast Track Technology Development Process . . . . . . . . . . . . . . . . . . . 5.4 Lean Process in Technology Development . . . . . . . . . . . . . . . . . . . . . 5.5 Some Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

75 75 78 79 80 82 83 84 86

6 Key to Successful Fast Track Innovation . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1 Overview of Product/Technology Development Process . . . . . . . . . . 6.2 Commercialization and Its Importance . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.1 Commercialization Pathways . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 A Few Words for Start-Ups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

87 87 89 92 92 94

Appendix A: Disclosure of Invention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

95

Appendix B: Mutual Non-disclosure Agreement . . . . . . . . . . . . . . . . . . . . . .

97

73 74

Appendix C: Business Model Canvas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Contents

xi

Appendix D: System Requirements Document . . . . . . . . . . . . . . . . . . . . . . . 103 Appendix E: System Requirement Document Template . . . . . . . . . . . . . . . 129 Appendix F: A3 Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 Appendix G: Risk Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

List of Figures

Fig. 1.1 Fig. 1.2 Fig. 1.3 Fig. 1.4 Fig. 1.5 Fig. 1.6 Fig. 2.1 Fig. 2.2 Fig. 2.3 Fig. 2.4 Fig. 2.5 Fig. 2.6 Fig. 2.7 Fig. 2.8 Fig. 2.9 Fig. 2.10 Fig. 2.11 Fig. 3.1 Fig. 3.2 Fig. 4.1 Fig. 4.2 Fig. 4.3 Fig. 4.4 Fig. 4.5 Fig. 4.6 Fig. 4.7 Fig. 4.8 Fig. 5.1 Fig. 5.2 Fig. 5.3

Definition of innovation by SRI . . . . . . . . . . . . . . . . . . . . . . . . . . . Sustainable innovation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Research-innovation-society linkage . . . . . . . . . . . . . . . . . . . . . . . Incremental innovation—breakthrough innovation . . . . . . . . . . . Innovation culture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scalable business model—validated business model domain . . . Red Ocean–Blue Ocean marketplace . . . . . . . . . . . . . . . . . . . . . . . Typical product life cycle and profit . . . . . . . . . . . . . . . . . . . . . . . Extending product life cycle with 2nd product . . . . . . . . . . . . . . . Typical effect of delayed product development . . . . . . . . . . . . . . . Technology development roadmap with milestones . . . . . . . . . . . Vision to roadmap to milestones . . . . . . . . . . . . . . . . . . . . . . . . . . Patent application timeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Business model canvas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Business model canvas—Amazon . . . . . . . . . . . . . . . . . . . . . . . . . Business model canvas—Airbnb . . . . . . . . . . . . . . . . . . . . . . . . . . Business model canvas—Uber . . . . . . . . . . . . . . . . . . . . . . . . . . . . Why a process is needed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Traditional “Waterfall” versus Concurrent engineering method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Activities of Systems engineering management . . . . . . . . . . . . . . Customer—stakeholder relationship . . . . . . . . . . . . . . . . . . . . . . . Typical stakeholder hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Stakeholder requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The design philosophy of function means analysis . . . . . . . . . . . . Typical concept description sheet . . . . . . . . . . . . . . . . . . . . . . . . . Systems engineering process diagram (V model) . . . . . . . . . . . . . Overall development time for the projects [7] . . . . . . . . . . . . . . . . Systems engineering best practice . . . . . . . . . . . . . . . . . . . . . . . . . A3 template for problem-solving . . . . . . . . . . . . . . . . . . . . . . . . . . 5 whys method illustration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 5 7 8 12 16 22 25 26 27 31 32 35 40 42 42 43 48 50 54 55 57 57 60 63 73 74 76 80 81 xiii

xiv

Fig. 5.4 Fig. 5.5 Fig. 5.6 Fig. 5.7 Fig. 6.1 Fig. 6.2

List of Figures

Typical P–I diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ideal fast track development process . . . . . . . . . . . . . . . . . . . . . . . Cycle of knowledge creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Risk-cost relationship with degree of systems engineering process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Complete process of product development . . . . . . . . . . . . . . . . . . Unique selling proposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

82 83 85 86 88 91

List of Tables

Table 1.1 Table 2.1 Table 3.1 Table 3.2 Table 3.3 Table 4.1 Table 4.2 Table 4.3 Table 4.4 Table 4.5 Table 4.6 Table 4.7 Table D.1 Table D.2 Table D.3 Table D.4

Discounted cash flow—net present value . . . . . . . . . . . . . . . . . . . Overview of different forms of IPR . . . . . . . . . . . . . . . . . . . . . . . Technology Readiness Level (TRL) . . . . . . . . . . . . . . . . . . . . . . . Customer acceptance level (CAL) . . . . . . . . . . . . . . . . . . . . . . . . Reported benefits of concurrent engineering . . . . . . . . . . . . . . . . An example of function means table . . . . . . . . . . . . . . . . . . . . . . Function means table with potential solution . . . . . . . . . . . . . . . Example of a typical completed Pugh matrix . . . . . . . . . . . . . . . Concept selection with weightage . . . . . . . . . . . . . . . . . . . . . . . . Benefits of well-written requirements . . . . . . . . . . . . . . . . . . . . . Requirement verification matrix . . . . . . . . . . . . . . . . . . . . . . . . . . Validation requirement matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . System stakeholders and their main area of interest . . . . . . . . . . External impact load scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . Applicable operational load scenarios . . . . . . . . . . . . . . . . . . . . . List of requirement verification methods . . . . . . . . . . . . . . . . . . .

18 34 46 47 50 59 59 61 62 66 69 70 110 111 111 126

xv

Chapter 1

Innovation and Innovation Ecosystem

Abstract ‘Innovation’ is a word that is being used extensively these days in every sphere of life. Technology innovation, design innovation, process innovation, business innovation, etc. are the words we keep on hearing often. In this chapter, the reader is introduced to the definitions of innovation and invention. The world is struggling for developing sustainable innovation, and hence, the principle behind sustainable innovation is discussed and presented. The driving force is compelling the mankind to innovate, and the process of innovation is discussed. The importance of ‘basic research’ and ‘applied research’ is also discussed. Classification of innovation activities is presented here. Incremental innovation, breakthrough innovation, and disruptive innovation are also discussed with some examples. Another classification of innovation based on fields of application is also discussed. The importance of creating a congenial innovation ecosystem in a typical corporate world environment is presented, and the importance of developing strategic innovation agenda is also discussed. Ecosystem to support start-ups is discussed. Funding plays an important role for every start-up, and for investing in any start-up, the investors tend to assess the value of the start-up before they invest in the company. A few methods commonly used for valuation of a start-up are also discussed to create awareness of the importance of valuation. Keywords Innovation · OECD · Stanford Research Institute · Patent · Inventive steps · Sustainable innovation · Return on investment · Basic research · Applied research · Research-innovation-society linkage · Incremental innovation · Breakthrough innovation · Disruptive innovation · Product innovation · Process innovation · Marketing innovation · Organizational innovation · Accidental innovation · Innovation ecosystem · Innovation culture · Strategic innovation agenda · Start-ups · Evangelists · Coworking space · Scalable business model · Funding and valuation of start-ups · Berkus method · Cost-to-duplicate method · Discounted cash flow method

© The Author(s), under exclusive license to Springer Nature Switzerland AG 2023 B. K. Datta, Fast-Track Innovation and Commercialization: Tools and Techniques, https://doi.org/10.1007/978-3-031-30375-3_1

1

2

1 Innovation and Innovation Ecosystem

1.1 Innovation Albert Einstein once said, “If I had 20 days to solve a problem, I would spend 19 days to define it” [1]. Innovation is a challenging topic, and although it has now become a very common word these days and is used in many different contexts, its definition can be widely different. One needs to appreciate that all innovations projects perhaps will not be solved with the same approach. Each innovation project is unique in nature and has to address a totally different sets of challenges. The only common factor among all innovation projects is they all try to find a solution that was not known before. In order to differentiate an innovation project from any other project, we need to define—what is innovation. A quick search in the literature has landed us with a number of definitions of innovation, which can be quite confusing to a person being introduced to this new field. Hence, defining innovation is considered essential before we try to address how to handle innovation.

1.1.1 Defining Innovation Although innovation is a very common word, one comes across a variety of definitions of innovation. We will not try to list out all the definitions flying around in the market. Instead, we shall try to take the essence out of the definitions generally available and try to make a usable meaning of it. Here are a few examples [2] of definition of innovation, proposed by some well-established people of various backgrounds who have excelled in their respective fields: As per Nick Skillicorn, Chief Editor of Ideatovalue.com and Founder/CEO of Improvides Innovation Consulting, innovation is ‘Turning an idea into a solution that adds value from a customer’s perspective.’ As per David Burkus, Associate Professor of Management at Oral Roberts University, innovation is ‘The application of ideas that are novel and useful.’ Gijs van Wulfen, a LinkedIn influencer and the author of the FORTH Innovation Methodology, has defined innovation as ‘A feasible relevant offering such as a product, service, process or experience with a viable business model that is perceived as new and is adopted by customers.’ Robert Brands is known as the Innovation Coach® and is a serial entrepreneur and innovation practitioner. As per him, innovation is ‘any variation goes, as long it includes ‘new,’ and it addresses customer needs and wants’. Mike Shipulski is an innovation thought leader, focusing on defining best practices and tools for Product and Technology Development and embedding them into company culture. As per him, innovation is ‘Work that delivers new goodness to new customers in new markets and thus it in a way that radically improves the profitability equation’.

1.1 Innovation

3

Jorge Barba is an innovation insurgent and a partner at Blu Maya, an innovation consultancy helping ordinary companies become extraordinary. His slogan is—innovation is ‘The future delivered’. If we need to have the same understanding of the word ‘innovation’ across the world, we need to use a common definition accepted universally. Organization for Economic Co-operation and Development (OECD) and Eurostat have developed an international reference guide for collecting and using data on innovation in Oslo Manual, and in this manual in Chap. 2 (Concepts for measuring innovation), the general definition of innovation is given. This definition is also referenced in ISO 56000:2021. Innovation is defined as follows: An innovation is a new or improved product or process (or combination thereof) that differs significantly from the unit’s previous products or processes and that has been made available to potential users (product) or brought into use by the unit (process). Innovation is something that is new, adds value, satisfies end user’s needs, and is future oriented. Each innovation takes us toward a better future and often makes our life easier. Stanford Research Institute (SRI) defines (as shown in Fig. 1.1) innovation as “The creation and delivery of new customer value in the marketplace with a sustainable business model for the enterprise” [3]. Therefore, innovation gets utilized by the target customers. It is easy to think that innovation must be products or technological solutions. But it can be anything that makes systems more efficient, creates value, increases customer satisfaction, quality, and usability or reduces errors. Innovation can also be a new application of something that others have already developed. A clever innovator can, after spotting potential for improvement, cleverly fill a gap in the market and combine inventions into products/services that will attract customers and generate commercial success. Innovation is successful only when it starts getting sold in the market and gets used. In this process, it contributes to the economic system of a society. Innovative people are always striving to accomplish a job in an easier way. Even kids improvise all the time. Nobody has a monopoly on creative thought. People often tend to think complex while trying to solve a problem. However, simple solutions are often more robust and can at the same time be very futuristic. Simple is beautiful. Fig. 1.1 Definition of innovation by SRI

4

1 Innovation and Innovation Ecosystem

1.1.2 Defining Invention People often tend to confuse between invention and innovation. As per Cambridge dictionary [4], “Invention is something that has never been made before, or the process of creating something that has never been made before”. An invention can be protected by patent, only if it meets the following requirements: ● It must be new. ● It must have inventive steps. ● It must be a technical solution. A. It must be new An invention must not form part of the state of the art (also known as prior art). The state of the art means all knowledge that has been made publicly available in any form anywhere in the world prior to applying for a patent. This includes any printed/online publications, lecture notes, public lectures, product brochures/flyers, and exhibitions. Therefore, before applying for a patent, secrecy should be maintained about the invention. B. It must have inventive steps In addition to being new, a patentable invention must have inventive step. This means that the invention must differ significantly from previous technology—prior art—in that field. It cannot be merely the next logical stage in a known technical process, obvious to someone with knowledge and experience in the subject field. In patent law, a “person skilled in the art” is a hypothetical person who knows the prior art in his specialist field but is unimaginative. If you show the purpose of your invention to a person skilled in the art and he readily comes up with the same solution as you, then your solution is not inventive and hence cannot be patented. C. It must be a technical solution Any patentable invention must have a technical character, and it must be possible to reproduce. A person skilled in the field should be able to understand and recreate the invention described or be able to perform the procedure, as described in the patent application and arrive at the same end result.

1.1.3 Sustainable Innovation By the word ‘sustainable innovation’ the author means environmentally sustainable innovation. If we consider the whole world as a marketplace and the society consists of the animal kingdom thriving in the environment offered by the nature, we must appreciate that we have very limited number of resources in terms of both natural resources and living resources. We must understand that we live in an ecosystem,

1.1 Innovation

5

and any thoughtless exploitation of resources will eventually deplete the resource and create imbalance in the nature, which may eventually lead to disastrous consequences. The Sustainable Development Goals [5] created by the United Nations call on all countries in this world (irrespective of size and financial capability) to make tangible improvements to the lives of their citizens taking due care of the environment. For a business to be viable, they need to utilize their resources (time, people, money, and raw materials) in an optimal manner such that the business can generate enough profit and enough return on investment so that the investors continue to support the company to run its business. However, with the deteriorating environmental conditions and increasing awareness of impact of human behavior on environment, it is becoming more and more important that business leaders also take account of environmental impact of their business activities. Younger generations are much more environment conscious than people were 50 years back. Earlier business houses were more concerned about profit and the people (employees), but now the focus is changing to 3Ps, i.e., people, profit, and planet. If we destroy the planet, then people will not be able to survive, and consequently, there will be no business or profit! Consumers are now putting pressure on the business houses to do business in such a way that it is not only good for the company but also good for the customers, communities, investors, and the planet. This demands that the companies start adopting ‘System Thinking’ in any innovation or production process and start documenting environment impact of any of their processes. This in turn demands a change of focus for both industry and the government. Sustainable innovation is any innovation that satisfies the needs for the society taking due consideration of the environment, economy, and the stakeholders at the same time (Fig. 1.2). Such innovation will not only meet the need of the current generation but also will not compromise the need of the future generations. Companies that engage in sustainable innovation think long term and will prioritize sustainability over short-term profit goals. Some examples of sustainable innovations are: 1. Groasis Growboxx [6, 7]—It is a tool for fighting food and water shortages. Groasis is a company located in Netherland and has innovated Growboxx made Fig. 1.2 Sustainable innovation

6

1 Innovation and Innovation Ecosystem

of recycled paper pulp which can be used for planting trees on sand dunes, burned forests, rocks and mountains, deserts, etc. 2. B-Droid [8]—Researchers from the Warsaw University of Technology are developing an automated pollinating drone. 3. Sustainable plastic from Newlight Technologies INC. [9]—They are producing cost-effective high-performance carbon-negative biomaterial to replace plastic. 4. Sharing economy—Car sharing and dress sharing are becoming popular, and such communities are growing up around the world slowly. It is getting more traction among the younger generation.

1.1.4 Driving Force Behind Innovation The process of understanding of the complexity of science is usually dealt with at the universities and research centers all around the world. Researchers usually try to understand the fundamentals of the underlying scientific process. In their pursuit of understanding the underlying process, they may sometimes tumble upon totally unexpected result/knowledge which can open new frontiers of knowledge or new application which was unknown before. Research can create the fundamental building blocks of understanding the process of science and nature. Solutions to any problem can be found only if we clearly understand the underlying phenomena, i.e., what is happening and how it is happening. This understanding of the process is the task of the researchers. Very often researchers get the liberty to pursue for knowledge in his/her chosen field of interest without many restrictions. The basic research can be defined as fundamental and investigative research (both theoretical and experimental) to advance knowledge without any particular application in mind. It is driven by curiosity of the mind and the joy of exploration of the unknown. This is the type of work usually done at universities and some R&D laboratories. There isn’t always a clearly defined outcome. The focus here is to learn more about how things work. It is all about learning about process. Longterm basic research opens up new doors, which were unknown earlier. This in turn can lead to new opportunities. Basic research pays huge dividends in the long run, and it’s difficult to imagine our modern world without discoveries and inventions, which seemed useless at the time they were in research stage. While basic research rarely leads directly to new products or services, many corporations invest serious money into it. Some companies, like IBM, have internal laboratories doing primary research, while others invest by way of research grants to outside scientists and academic affiliations. Another breed of researchers is applied researchers. In this case of applied research, the researchers are very much focused on the end users’ needs and on finding answer to specific questions that have direct application and impact on the society. Such applied research happens mostly in research centers or at the R&D units of some companies. Applied researchers are very much focused on generating knowledge for solving some practical problems faced by their customers or end users. The integration of the knowledge form basic research with applied research

1.1 Innovation

7

Fig. 1.3 Research-innovation-society linkage

is extremely vital for problem solving, innovation, and development of new products/services. It is much closely linked to innovation than basic research. Such applied research is often done in collaboration with industrial partners, community groups, or governments, and in the process of innovation, they create often new technologies and new processes with significant enhancement of product quality and may lead to new patents. If we take a step back and try to understand why we innovate, the answer will be: to solve some problems/challenges faced by us. This means that any knowledge generation process is very much linked to understanding and generating solutions to problems/challenges faced by the society. Innovation process is the vehicle of conversion of knowledge into applications that will benefit the society as depicted in Fig. 1.3. Apparently, people tend to forget the importance of knowledge generation through research. It takes years of research and perhaps thousands of publications to understand the basics of a scientific phenomenon. Research generates knowledge, which is then made available for the society to exploit/utilize for solving problems/challenges. Anybody or any group of people with innovative skills and an understanding of the needs of the end users and the possibilities that an innovation can create usually puts efforts to develop some product/services. These products/services are then made available to the society. If the society is ready to accept and utilize the same, then it starts using. The experience and feedback from the end users then go back to the researchers, who then undertakes further research and generates new knowledge which in turn goes into developing further advances in products/services. This goes on continuously and thus happens technological development.

1.1.5 Classification of Innovation Activities The most successful economies are driven by innovative industries that evolve to meet the needs of a changing world. From the advances that put a computer on every desk to the discoveries that led to lifesaving vaccines, major innovations are the result of both government investments in basic research and the private-sector creativity and investments that turn them into transformative products [10]. Innovation activities

8

1 Innovation and Innovation Ecosystem

can be classified into three broad categories based on nature of innovation and its impact on the society/market: Incremental Innovation: This is the type of innovation that has often a clearly defined problem and a reasonably good understanding of how to solve it to start with. In the literature, the use of ‘sustaining innovation’ and ‘incremental innovation’ can be found. However, in both cases, it involves only an improvement of the existing product/process/services with varying degree of improvement. The author would use the term incremental innovation to cover both types as they both have similar nature of innovation. It is probably the most common in the corporate world and is often referred to as engineering rather than science. It does not create new markets, but rather develops existing ones with better value. Such innovation happens on an incremental basis, often in response to customer or market demand, or technology improvements. Gradual shift in knowledge boundary and value-cost boundary takes place in incremental innovation as shown in Fig. 1.4. Maintaining open channels for feedback and communication allows businesses to constantly improve and provide greater value to customers and the market. Like basic research, much of this is done by internal R&D staff, but many companies

Fig. 1.4 Incremental innovation—breakthrough innovation

1.1 Innovation

9

outsource it as well. Steve Jobs wanted to create a device that would allow you to put “1000 songs in your pocket.” That meant you needed to have a certain amount of memory fit into certain dimensions. Those were difficult problems that took a few years to solve, but it was clear what was involved from the very start. Other examples of incremental innovation can be found in TV models which are on a regular basis being upgraded and newer models being launched. Breakthrough Innovation: Often, a particular scientific/technological field has trouble moving forward because they need a new approach. That’s why breakthroughs often come from newcomers. It involves a paradigm shift. It can potentially reshape existing markets, create new markets, and prompt the emergence of new technological developments. In this case, the problem is well defined, but the path to the solution is unclear, usually because those involved in the domain have hit a wall. A sudden jump to a new knowledge boundary is achieved in breakthrough innovation, as graphically presented in Fig. 1.4. A classic example of breakthrough innovation is the discovery of the doublehelical structure of DNA [11] by James Watson and Francis Crick in 1953, which laid the foundations for the subsequent work done in the fields of genetics. The need to find the structure of DNA was a very well-defined problem, but the top scientists struggled for a long time before one could find the answer. This discovery yielded ground-breaking insights into the genetic code and protein synthesis. LED lights and LED screens are other examples of breakthrough innovation. Another example can be found in the use of messenger RNA (mRNA) technology for developing vaccine for corona. mRNA vaccines can be modified easily and quickly to treat mutating viruses. mRNA also shows promise for treating cancer [12]. Disruptive Innovation: Disruptive innovation is particularly tricky because you don’t know it until you see it, and sometimes, its value isn’t immediately clear. Disruptive innovation can create a totally new market or a totally new value-cost frontier that can easily compete with existing players in the market. Existing players in the market are usually fighting with each other to get a market share by either lowering the price or by adding some additional value to the current product in the market. The new entrant in the market using disruptive innovation has a totally different value-cost structure which none of the existing players can beat. Disruptive innovation generates new products, markets, and values to disrupt existing ones. Disruptive innovation is accomplished through a combination of uncovering new categories of customers and lowering costs and enhancing quality in the existing market. This is usually done by utilizing new technologies and business models and/or exploiting old technologies in totally new ways. There is also a growing trend toward corporate innovation laboratories, which work closely with start-ups to perform ongoing “test and learn” programs that help identify promising new technologies before they are fully mature. The author would suggest that reader take a note of ‘test and learn’ process used in innovations. This is quite effective process and will be discussed later in Chaps. 4 and 5. Disruptive innovation often challenges and defeats traditional business models and replaces them with new ones. One example of this is Netflix. At first, they presented a breakthrough innovation

10

1 Innovation and Innovation Ecosystem

by introducing a subscription model that delivered DVDs to people through the mail, but then they disrupted the entire home entertainment industry by introducing streaming services and becoming a content producer themselves. Another example is Google search engine. It has made possible to find answers by writing questions in simple words and by pressing one click! ‘Google it’ is now a common word for searching the web. ‘Uber’ is another example. Uber has created a new marketplace and has created opportunities for both passengers and drivers based on individual needs. Uber doesn’t own a single car and yet provides easily accessible, affordable, and comfortable transportation modes. Chat Generative by Pre-trained Transformer (ChatGPT), a chatbot launched by OpenAI, is another example. Innovation can also be classified based on field of application [13]. Depending on field of application, innovation can be classified into four categories: ● ● ● ●

Product innovation Process innovation Marketing innovation Organizational innovation.

The term “product” is used to cover both goods and services. A product innovation is the development of goods or services that is new or significantly improved with respect to its characteristics or intended uses. This includes significant improvements in technical specifications, components, materials, software, and/or other functional characteristics. A process innovation is the implementation of a new or significantly improved production or delivery process. This includes significant changes in techniques, equipment, control mechanism, and/or software. Process innovations can be intended to decrease unit costs of production or delivery, to enhance quality, or to produce or deliver new or significantly improved products. Marketing innovation is the implementation of a new marketing method involving significant changes in product design or packaging, product placement, product promotion, or pricing. Marketing innovations are aimed at opening up new markets, or better positioning a company’s product on the market, with the objective of increasing the company’s market share. An organizational innovation is the implementation of a new organizational structure in the company’s business practices, workplace organization, or external relations. Organizational innovations can be intended to increase a company’s performance by reducing administrative costs or transaction costs, reducing administration bottlenecks, improving workplace satisfaction (and thus labor productivity), or reducing costs of supplies.

1.1 Innovation

11

1.1.6 Accidental Innovation Although people have more than often tried to develop something new with methodical approach, there are several instances where inventions were made just by accident or because of some mistakes made during the methodical process. Some of such accidental inventions which had huge impact are presented here. Discovery of Penicillin [14]—In 1928, a bacteriologist, Sir Alexander Fleming, after returning from a vacation back to his London laboratory noticed a zone around an invading fungus on an agar plate, where the bacteria did not grow. Fleming isolated the mold and obtained an extract from the mold and named it as Penicillin. Although Fleming published his findings in 1929, it took quite some time till it was developed as medicine in the market around 1943. Discovery of X-ray [15]—In the year 1895, Professor William Conard Roentgen, at Wuerzburg University in Germany, was testing whether cathode rays could pass through glass. The cathode tube was heavily covered with black paper, and he never expected that any ray would pass through. However, he noticed that a green colored florescent light was generated on a material located a few feet away from the cathode tube. He then found that the newly discovered ray could pass through most materials and created shadows of only some solid objects; for example, the ray could pass through human tissues but not bones and metals. He called this ray ‘X’ meaning ‘unknown’. Invention of Pacemaker [16]—Wilson Greatbatch, an adjunct professor at the University of Buffalo, by mistake used a wrong transistor while trying to develop an equipment for recording heartbeat, and suddenly, he observed that instead of recording, it was emitting electrical pulse mimicking the heartbeat. He immediately realized that the device could help a weak heart by delivering electrical pulse to help it beat in rhythm. This led to the development of cardiac pacemaker at a later date. Invention of Viagra [17]—In the year 1980s, Pfizer was developing Sildenafil to treat cardiovascular problems, and it was intended to dilate the heart’s blood vessel by blocking a particular protein. Although the results were looking good, one day a dutiful nurse suddenly noticed that a lot of men were lying on their stomach trying to avoid embarrassment due to unwanted erections. This led to the further development of the drug Viagra as it is known today. In 1998, Viagra was approved by the US Food & Drug Administration for use as an erectile dysfunction drug. Invention of Safety glass [18]—In 1903, a French scientist, Edward Benedictus, was trying to grab a flask from a shelf high up standing on a ladder. By mistake, the flask slipped from his hand and fell on the floor. But to his surprise, the glass flask maintained its shape, and there were no glass fragments on the floor. After investigation, it was revealed that one of his assistants did not clean the flask properly after it was used in some experiment with cellulose nitrate. The liquid cellulose nitrate evaporated leaving a thin layer on the inside of the flask, thereby creating an adhesive layer, which prevented the flask getting broken in pieces.

12

1 Innovation and Innovation Ecosystem

Invention of microwave [19]—Percy LeBaron Spencer, an engineer at the company Raytheon in USA, was working on improving the power level of the magnetron tubes to be used in radar sets. During testing of one of the magnetorn tubes, he suddenly realized that chocolate bar in his pocket was melting! Percy got curious, and to understand the phenomenon better, he put an egg under the tube. The egg exploded under the magnetron tube moments later. Next day, he ran another test with corn kernels, and it produced popcorns! Thus was the modern microwave born. Microwave oven was patented on October 8, 1945. Invention of Velcro [20]—In 1941, George de Mestral, a Swiss electrical engineer, while walking through the woods on a hunting trip with his dog noticed cockleburs sticking to his clothes and the fur of his dog. Being a curious engineer, he inspected the burrs under microscope and understood that the mechanism of the hooks of the burrs sticking to the loops of the fur and fabric. This led to the development of Velcro as we know it today. This invention was patented in 1955.

1.2 Innovation Ecosystem in Corporate World Innovation is not an easy task, and not every company/institution is well placed to innovate either. If a company wants to develop a positive atmosphere to promote inhouse innovation activities, it needs to create an ecosystem congenial for allowing employees to think innovative. There are some basic requirements for an ecosystem to be congenial for innovation. A robust innovation policy and a congenial ecosystem can make a big difference. Innovation culture needs to be cultivated for a prolonged period until it becomes inbuilt in the system. A model of fostering innovation culture in a company is presented in Fig. 1.5. To achieve this, the following four elements must be in place:

Fig. 1.5 Innovation culture

1.2 Innovation Ecosystem in Corporate World

1. 2. 3. 4.

13

Strategy/goal Positive management role Employees’ participation Well-defined success criteria.

Strategy/Goal: One needs to define the goal/strategy clearly. Once the goal is well defined, competent groups of people can be assigned to find a solution. Unfortunately, every problem can have several solutions. Cost and time involved in case of the different solutions can vary quite widely. Further, innovation involves solving some unknown challenges, and hence, chances of failure will always be there. Learning from these failures is a very important process of innovation. The company management needs to understand the challenges of innovation, show flexibility, and should be able to tolerate risks and failures involved. Innovation must be aligned with strategy of the company. Company management/technology development manager has to plan as to how much efforts should be put on improving existing products/processes, finding way to adjacent technologies, and exploring completely new technology for a new market segment. Employees: Every organization has a set of capabilities, and often organizations are structured in a way so that they can carry out a certain set of activities in a very optimized and efficient manner. People in such organizations often carry out routine activities, and they become very efficient over time. However, when it comes to developing new technologies most often, they are not best suited for the job. Although they may not be best suited, they have the hands-on understanding of the day-to-day technical challenges they face and that can lead to an innovative solution. Technology development needs a group of competent people who can think new and have problem-solving skills. Employees with freedom to think new can generate many innovative solutions. They must be assured by the management that, ‘it is natural to make mistakes and learn from the mistakes in the process of innovation.’ Management: Even if you have both competent team and strategy in pace, one needs to manage innovation activities effectively to reach the market fast at a reasonable cost. The top management must promote a culture for innovation and challenge the employees to innovate. They must show flexibility when it comes to supporting innovative environment, providing the needed resources and help building connection between the innovators and the industry (end user). Success criteria: There must be transparency in the innovation process, and any innovation must be able to satisfy the need of the target user group. Any innovation activity costs money, and hence, the target market size is important in order to have an impact from the innovation. Any innovation should also have a positive societal impact. In some progressive thinking companies, it is not uncommon to offer incentives to the creative minds. The innovative people are hungry to get recognized for their contribution and rarely get inspired by only monetary incentive. They want to see their innovative solutions accepted and realized. Token monetary incentive to the inventors for a granted patent is quite common. Some companies allow innovative

14

1 Innovation and Innovation Ecosystem

people a certain amount of time for cultivating their innovative thought process on a regular basis. An annual prize for most innovative solution is also practiced in some companies.

1.2.1 Creating Strategic Innovation Agenda The decision to pursue innovation seriously in any company must come from the top management with their full understanding of the challenges and benefits for the company and the society. Innovation is often a journey with several unknown parameters that need to be defined as one moves on toward the goal. Before starting innovation process, the company has to prepare a roadmap for the innovation process with clearly defined goals. Key elements to remember for successful innovation are: ● ● ● ● ● ●

Customers are key to success. Problems/challenges need to be identified. Challenges need to be very clearly defined. Challenges need to be broken down into manageable components. Solutions to these components got be addressed. The total solution is then taken to the market to make customer’s life easier/comfortable.

‘Anything that won’t sale, I don’t want to invent’—Thomas Edison [21]. Innovation roadmap depicts a plan for innovation targets graphically along a time axis. Typically, companies tend to develop both short term (3–5 years) and long term (10–15 years) plans. Such roadmaps will often consider the following: ● ● ● ● ● ●

Status of business Assessment of core strengths and weaknesses Visible competitors Technology/business development trends Stakeholder requirements Technology development/merger/acquisition strategy.

The goal of the road mapping is to develop the innovation strategy—to choose the right strategy from different options and do the right things in order to maximize the benefit for the company. The goal of innovation management is to implement this strategy well. Road mapping leads to effective project portfolio development and management. It provides for company-wide technological strategy development and technology assessment, as well as project evaluation and strategic aligning at unit levels. Road mapping tool provides also a transparent platform for communicating innovation across technologists, business managers, suppliers, and customers. The task of the roadmap team is to formulate the potential development scenario that will indicate potential technology disruptions within the industry. With a general industry map and a potential development scenario, one can easily identify current players

1.3 Innovation Ecosystem for Start-Ups

15

in the industry, the future potential players, and financial opportunities. This will in turn point at the need for strategic partnerships in order to get access to necessary competencies and consequently gain market share. While “incremental” innovation resources and efforts are usually and correctly within the responsibility of product/group managers, business managers, etc., the pursuit of “breakthrough” is the responsibility of the Boardroom, the CEO, and his/her direct reports. Although they aren’t the ones doing the actual day-to-day work, the ultimate responsibility for growth and long-term viability of the company is theirs! Breakthrough innovation is strategic innovation. It is risky, it requires a long-term commitment, and when in pursuit of a major new growth opportunity, it requires investment of resources that only the top management can ensure. “The human mind treats a new idea in the same way the body treats a strange protein; it rejects it”—This is a quote from Sir Peter Brian Medawar, a renowned Brazilian-British biologist. This happens all the time in our everyday life and especially so in an organization, unless it has a dedicated group of people with assigned tasks of innovation. The line managers are often struggling to maximize output with limited resources and hence have very little flexibility. They tend to say “NO” to any new idea if an employee would like to pursue the idea that might affect the regular output. Only the CEOs in any organization can say “YES” without taking permission from any other person! CEOs have a responsibility to develop the business further based on the foundation of the current business. Successful CEOs are usually visionaries, and they tend to protect the resources treading the risky path of innovation efforts. Understanding that failure is part of the process, and giving their innovators reassurance and motivation over long-term must come from the top management.

1.3 Innovation Ecosystem for Start-Ups A start-up is a business venture usually initiated by its founder(s) around a concept for solving a problem which potentially has significant impact on the market and scalable business opportunity. A start-up needs to develop the concept into a product/service/business model following an innovation process. A start-up characteristically develops a business model which is not yet validated as opposed to a ‘scale-up’ business or ‘small business’, which follow validated business model. Typical placement of ‘start-up’, ‘scale-up’, and ‘small’ business in a scalable business model—validated business model domain, is shown in Fig. 1.6. A start-up needs people around it to help develop the idea, get the idea validated, develop the idea into a product, launch the product, reach the market, get recognized in the market, and grow. It has now been well established that start-ups need to be placed in an ecosystem congenial for their development and success. All over the world, ecosystems are being developed to help start-ups to succeed in their endeavor. A start-up ecosystem ideally should consist of:

16

1 Innovation and Innovation Ecosystem

Fig. 1.6 Scalable business model—validated business model domain

● Evangelists—They are individuals who are ready to engage with the start-ups as mentors. They not only believe in the potential success of the company, but also convince all non-believers of the value of the company. ● Advisory group—A group of experts often need to support a start-up as they keep developing the technology, business plan, marketing plan, manufacturing plan, and sales plan. ● Coworking space with start-ups at various stages of development—They often act as a source of inspiration for the start-up and can be a source of learning in the process of development of the business venture. ● Universities and research centers—These can act as discipline experts in their respective fields. Easy access to such facilities can be a key to success. ● Funding agencies—Although initial funding often comes from family and friends, there is also possibility of pre-seed funding from various agencies. Typically, these are available from incubator organizations. Normally, this is made available at a very early stage of development when the risks are very high. Seed funding usually comes from government agencies with earmarked funds for various identified market segments. Some private agencies can also have similar funds available. In Norway, for example, seed funds can be sought from Innovation Norway. Crowdfunding can be another source of getting access to funding. Next stages of funding usually come from venture capital firms at different stages of development until the start-up decides to go for Initial Public Funding (IPO). A start-up ecosystem

1.3 Innovation Ecosystem for Start-Ups

17

usually has access to investor network, and they can easily facilitate connection between the investor and the start-up. ● Various support organizations—Consulting, accounting, legal, patenting, etc. are typical services made available in such ecosystems. ● Access to big companies—The start-up ecosystem management usually acts as bridge-maker between large companies and the start-ups. Many large companies are always on the lookout for new, smart, scalable technologies which they can absorb easily in their companies. Start-ups getting purchased up by large companies are not uncommon at all. With high-speed internet getting available in almost all parts of the world, ecosystems all around the world are getting connected, sharing information, and developing global solutions, except for the countries who prefer to remain isolated due to geopolitical reasons.

1.3.1 Funding and Valuation of a Start-Up Start-ups will be approaching various investors during their lifetime at various stages of development. Getting access to the very initial funds at pre-seed stage can be quite difficult. At this stage, the company often has only business plan and concept, which is not yet fully developed. This makes it difficult for the start-up to document its worth. Valuation of a business is never easy even for an established business with steady revenues and earnings although various parameters like earnings before interest, taxes, depreciation and amortization, or industry-specific multipliers can be used. However, valuation of a start-up with no revenue or profit can be very challenging. Usually, such companies take a few years to generate sales and later get publicly listed. Start-up companies often look for investors to support in their venture. In such situation, if any private investor or any investor, for that matter, considers investing money, they would like to understand the company’s worth. Naturally, it will be of advantage, if the entrepreneur (start-up owner) is well prepared and documented the company’s worth beforehand. A few methods for calculating Net Present Value (NPV) of a start-up that can be used are presented here: 1. Berkus valuation method 2. Cost-to-duplicate 3. Discounted cash flow. Berkus method—This method is normally used to calculate the start-up’s earlystage value before the first revenue is generated. This method was created by David W. Berkus, an American angel investor and venture capitalist from California in the 1990s. This method is also known as ‘Development stage valuation approach’. This approach assigns a value on each of five key success factors, i.e., 1. Sound idea (viable business model)—It represents the base value. 2. Available prototype—Maturity of prototype reduces the risk.

18

1 Innovation and Innovation Ecosystem

3. Management team quality—Good-quality management teams reduce implementation risks. 4. Strategic relationships in the core market—An established relationship reduces market acceptance risks. 5. Existing customers/customer engagement—Reduces risks of sales. Berkus model in original form assigned a value from 0 to 500,000 US$ to each factor and then sums up the total to arrive at a value for the company. The upper value can be adjusted to the location of the start-up to reflect the local economic scenario. This type of pre-money valuation is very much subjective and needs experienced investor to assess. Pre-money valuation is the value of the company (i.e., how much a start-up is worth) before receiving investments. Pre-money valuation will depend very much on the location of the start-up also. According to AngelList valuation data [22], the average pre-money valuation in USA has varied from around US $5 M to US $10 M during 2017–2021 and has an increasing trend. Cost-to-duplicate method—This method is quite simple and is based on how much it would cost to recreate the company to the current state. The idea is that a potential investor will not pay more than it has cost the company to reach the current stage. It has some serious weaknesses as it does not consider: 1. 2. 3. 4. 5.

Intangible assets Management team capability Market connection Market reputation Future potential sales, etc.

Discounted cash flow—This method is perhaps most important for valuation of a start-up as it values an enterprise not on its current performance but on the future potential down the line. A rate of return on investment, called the “discount rate,” is assigned for the start-up and used to calculate the current worth of the projected cash flow in subsequent years. Since investments in start-ups are usually associated with high risk, a high discount rate is generally used. The current Net Present Value (NPV) of the start-up is then calculated. An example is given below (Table 1.1): The above calculation shows that even though the current undiscounted cash flow (year 0) is negative, the Net Present Value is positive, and hence, investment in such Table 1.1 Discounted cash flow—net present value Discount rate

10%

Formula for calculating discount factor

1/(1 + discount rate)^time

Year

0

1

2

3

4

5

Undiscounted cash flow

−30,000

5000

10,000

10,000

10,000

10,000

Calculated discount factor

1.00

0.909

0.8264

0.7513

0.683

0.6209

Present value

−30,000

4545

8264

7513

6830

6209

Net present value

3 361

References

19

a situation will be considered positive. However, if the current undiscounted cash flow is set to—40,000, the NPV will become negative, and hence, investment in such a company will be considered risky. The author suggests the start-ups should make themselves aware of various methods of calculating the Net Present Value used by the investors. While the startups would like to see highest value for their company, the investors would like to set the valuation to the minimum.

References 1. Satell G. Before you innovate, ask the right questions. Harvard Bus Rev. [Internett]. https:// hbr.org/2013/02/before-you-innovate-ask-the-ri. 11 Feb 2013 2. Idea to value. Idea to value. [Internett]. https://www.ideatovalue.com/inno/nickskillicorn/2016/ 03/innovation-15-experts-share-innovation-definition/ 3. Jeffrey W (2015) NEDO Forum—Innovation for a brighter future. [Internett] Feb 2015. https:// www.nedo.go.jp/nedoforum2015/program/pdf/gs/william_jeffrey.pdf 4. Cambridge dictionary 5. United Nations. Sustainable development goals. [Internett] United Nations. https://www.un. org/sustainabledevelopment/sustainable-development-goals/ 6. Groasis BV. Biodegradable Growboxx® plant cocoon. [Internett]. https://www.groasis.com/en/ technology/the-groasis-growboxx-plantcocoon-biodegradable-it-is-made-of-recycled-paper 7. Government of the Netherlands. Groasis Growboxx® fights food and water. [Internett]. https://www.groasis.com/images/image/Factsheet/20171209-National-Icon-Groasis-Ecolog ical-Water-Saving-Technology-Factsheet.pdf 8. Bukowska M. B-Droid—a robot that’s busy as a bee. [Internett]. Warsaw University of Technology. https://www.pw.edu.pl/engpw/Research/Business-Innovations-Technology-BITof-WUT/B-Droid-a-robot-that-s-busy-as-a-bee 9. Newlight Technologies, Inc. [Internett]. https://www.newlight.com/technology 10. Gates B. Innovative Leadership—Accelerating innovation with leadership. GatesNotes. [Internett] The blog of Bill Gates, 6 Oct 2016. https://www.gatesnotes.com/About-Bill-Gates/Acc elerating-Innovation 11. Francis Crick—The Francis Crick Papers. [Internett] National Library of Medicine, 8600 Rockville Pike, Bethesda, MD 20894. https://profiles.nlm.nih.gov/spotlight/sc/feature/double helix 12. World changing MRNA vaccines from Penn Medicine. [Internett] Penn Medicine. https://www. pennmedicine.org/mrna#future-of-mrna 13. OECD/Eurostat (2018) Oslo manual 2018: guidelines for collecting, reporting and using data on innovation. [Internett]. https://doi.org/10.1787/9789264304604-en 14. Gaynes R (2017) The discovery of penicillin—new insights after more than 75 years of clinical use. Emerg Infect Dis 23(5) 15. History of Medicine: Dr. Roentgen’s accidental X-rays. [Internett] Columbia University Irving Medical Center. https://columbiasurgery.org/news/2015/09/17/history-medicine-dr-roentgens-accidental-x-rays 16. Greatbatch W (2000) The making of the pacemaker: celebrating a lifesaving invention. s.l.: Prometheus, 1st edn. ISBN-10.1573928062 17. Osterloh IH. The discovery and development of Viagra® (sildenafil citrate). [bokforf.] U. Dunzendorfer. Sildenafil. Milestones in Drug Therapy MDT. s.l.: Birkhäuser, Basel 18. Schwarcz J. What is safety glass? [Internett]. https://www.mcgill.ca/oss/article/history-youasked/what-safety-glass. 2 July 2021

20

1 Innovation and Innovation Ecosystem

19. Blitz M. The amazing true story of how the microwave was invented by accident. Popular Mechanics. [Internett]. https://www.popularmechanics.com/technology/gadgets/a19567/howthe-microwave-was-invented-by-accident/. 20 Oct 2022 20. Biomimicry—The Burr and the Invention of Velcro. Micrro Photonics Inc. [Internett] Micro Photonics Inc. https://www.microphotonics.com/biomimicry-burr-invention-velcro/ 21. Famous Quotations from Thomas Edison. [Internet] Edison innovation foundation. https:// www.thomasedison.org/edison-quotes. Sitert: 11 July 2022 22. Othman A et al (2021) The state of U.S. Early Stage Venture & Startups: [Internett] 31 Jan 2022. https://assets-global.website-files.com/5f34db2422dcee712f853aa0/61f829e71975 5b38229071af_StateofVentureAndStartupSpendReport2021.pdf

Chapter 2

Strategic Technology Development Process

Abstract Every company tries to create an offering that the current market needs. Progressive thinking companies often try to create an offering which is not available in the market and there is a demand for the product/services. Thus, they can create a unique position for themselves and thereby can grab a large market share, being first in the market. The concept of ‘red ocean’ and ‘blue ocean’ marketplace is discussed, and its relevance to technology development is also highlighted. Shifting value-cost frontier in incremental innovation and creation of blue ocean market by disruptive and breakthrough innovation is discussed. The reason and need for value creation for customers and other stakeholders are discussed. A typical product life cycle and the variation of profit margin during the life cycle are presented. The importance of the timing of innovative product development cycle and introduction of new products is explained in relation to profit generation. Consequence of late product development on the company’s economy is also highlighted. Pricing strategy and the importance of communication of ‘Value proposition’ are discussed briefly. This chapter discusses the need for a well-formulated technology development roadmap and the importance of a well-defined problem in enabling the development of the most suitable solution. The reader is introduced to disclosure of invention, various types of intellectual property, and protection of intellectual property rights. The need for assessment of market and IPR is discussed. The importance of ‘time to market’ in the product development process is also touched upon briefly. The reader is also introduced to the need for development of a suitable business model and the use of business model canvas to create a total overview of the business and identify important potential partners, etc., at a very early stage of product development process. Keywords Red ocean strategy · Blue ocean strategy · Value creation · Product life cycle · Innovation management · Pricing strategy · Value proposition · Technology strategy · Technology roadmap · Disclosure of invention · Intellectual property · Patent · Trademark · Design · Copyright · Patenting process · Priority application · PCT application · Non-disclosure agreement · Market/IPR assessment · Time to market · Business model · Business model canvas

© The Author(s), under exclusive license to Springer Nature Switzerland AG 2023 B. K. Datta, Fast-Track Innovation and Commercialization: Tools and Techniques, https://doi.org/10.1007/978-3-031-30375-3_2

21

22

2 Strategic Technology Development Process

2.1 Red Ocean Versus Blue Ocean Strategy Every business depending on technological advantages over their competitors is always on the lookout for creating an edge over the others in the marketplace. Technologists must get accustomed to the fast-changing technology landscape and adjust or upgrade their technology offerings addressing the demand of the market. In any marketplace, several players (companies) try to compete, and everyone tries to get a bigger market share. This competing market scenario has been termed as ‘red ocean’. The concept of ‘red ocean’ and ‘blue ocean’ was first introduced by Prof W. Chan Kim and Prof. Renée Mauborgne, from the INSEAD Blue Ocean Strategy Institute, in their book ‘Blue Ocean Strategy—How to Create Uncontested Market Space and Make the Competition Irrelevant’. Red Ocean represents a marketplace with severe competition in the market, where each competitor is trying to get an edge over the other and trying to secure a fair share of the market and profit. However, the cutthroat competition results in a bloody marketplace, coined as ‘Red Ocean’, of rivals fighting for survival with consequent shrinking profit over time. In this marketplace, everybody is fighting for survival and trying to gain a market share by reducing cost or adding some marginal value as compared to the rivals. Consequently, the profit margin sinks. Under such situation, it is quite common that after a while some competitors crumble under market pressure and are thrown out of the market. The companies practicing ‘Incremental Innovation’ operate in the Red Ocean (Fig. 2.1). Blue Ocean on the other hand represents the dream landscape for the innovators/entrepreneurs, who try to come up with new products (new Value proposition) Fig. 2.1 Red Ocean–Blue Ocean marketplace

2.2 Value Creation

23

that has no competitors in sight and thereby gets access to huge market (coined as ‘Blue Ocean’) with no boundaries. It is an unchallenged market space where the entrepreneur can sail and carry on business until a competitor arrives. With Blue Ocean strategy, it is also possible to break away from the Red Ocean by creating a new market with a value proposition that no other competitor in the market is capable of at that point of time or has in their offering. In Blue Ocean strategy, the new value proposition connects to the huge unexplored market of customer need, where no other competitors are present. Any innovation that also adds value for the customer which no other competitor can offer and at the same time can be offered at low cost can create an ocean (Blue Ocean) of market opportunities. Disruptive innovation may lead to creation of ‘Blue Ocean’ marketplace for the company.

2.2 Value Creation The purpose of any business is to create value for its customers at a reasonable cost so that the customer can afford to purchase it. A company can produce an excellent product but if there is no customer to buy and use the product, the company will not survive. For creating a product (or services), the company will need resources, which may include access to money from investors, manpower to carry out the tasks and partners who will take various roles in the value creation process and thereby gets their fair share of value. In traditional financial world, value creation will normally mean return on investment and earning profit. However, in broader sense in today’s world, it also includes societal beneficial value, brand, satisfied workforce, satisfied customers, etc. From an investor point of view, if return on investment is same for two projects—one dealing with creating new jobs and creating greener environment and the other creating weapons, investor may choose to invest in the project creating greener environment because it gives an additional value of creating a good brand image for the investor. Similar motivation can also be the driving factor for many employees and the partners. If we sit back and look at the bigger picture, we will see that the society is evolving toward a greener society, technology is getting developed at a fast pace, IT industry has transformed its profile with the advent of artificial intelligence and machine learning, and customer expectations are also crossing barriers all the time. In order to attract customers to buy a product, it has to offer certain value for the customer at a reasonable cost! Customers are always weighing value and cost when making any purchase decision. In the aspect of value, it is becoming more and more common to take account of environmental impact of the product. We see that ‘Value Creation’ is of utmost importance for any business and value must be created for the customers, the employees and the investors! Satisfied customers will generate demand while satisfied employees will create the product at a more efficient manner as the productivity goes up with increase in employee satisfaction. Pricing of the product must be made in such a manner that it generates

24

2 Strategic Technology Development Process

sufficient profit for the investors and at the same time keep the customers happy! Outstanding customer experience can only be achieved with effective value creation from customer’s perspective. ● Create new value—Creating new value is difficult because this involves creating something totally new that the potential customers have no experience with. This can be developing a new product/service for a new market. ● Create additional value—It is comparatively easier because in this case most often the process for making the product can be made more efficient and thereby it can be possible to offer more for the same price or same product for lesser price. In another scenario, there may already be lying some additional values in the product (for example, it may be a ecology-friendly product) which have not been made known to the customers. Environment-conscious customers are often willing to pay more price for ecology-friendly products. ● Create better value—This can be another strategy where improvement can be made on the existing product that already exists. Better quality product can be one example. Understanding customers’ perspective and evolving need of the customer segment is the key to success. Most companies, particularly well-established traditional companies often get stuck by their traditional thought process. Many businesses are afraid to change because they worry that such change may adversely affect the business rather than help! Such companies, if able to break out of their shell of fear, can easily improve value by understanding the evolving nature of the marketplace and the changing need of the customers. One example: Earlier, it was usual to receive the laboratory analysis reports by post, later it became normal practice to send by email. But these days, it is quite common to allow customers to log on to a digital platform and get access to the results. This can reduce both cost and time for the customer and at the same time ensure better customer experience. A happy customer is always good for growing business. A successful company usually focuses more on the value they are selling to the customer and enhanced customer experience, rather than trying to convince the customer about the price of the product. ‘Break the rule and make a difference’ can help a big way for such traditional companies to start creating values for their customers. Value innovation is defined as simultaneous effort to differentiate the product from those available in the market and also pursue low cost. If some technology innovation can create differentiation and at the same time can offer the same at an affordable cost, then an ocean of opportunities will open up.

2.3 Product Life Cycle and Importance of Innovation Management

25

2.3 Product Life Cycle and Importance of Innovation Management The importance of strategic innovation management to introduce the new product at the right time in order to ensure extended period of considerable profit cannot be ignored. To understand this, one needs to get familiar with the various stages of product life cycle and a typical picture of profit generated during all the stages of a product life cycle. Incremental innovation is what most companies try to achieve continuously. Product life cycle is limited, and hence, one tends to plan technology development activities in a strategic manner so that the company can exploit the market to maximize its benefit. A typical product life cycle is shown in Fig. 2.2. It can be easily seen that the product does not generate any profit during the ‘Product development phase’ and the ‘Introduction phase.’ It takes a while from the point of introduction of the product in the market to the break-even point, after which it starts generating profit. The product sales grow thereafter until it reaches a saturation level. Companies would like to see the product continue at this maximum profit level as long as possible. However, after a while competitors enter the market and market share tends to fall. Prices are adjusted downwards to remain competitive at the cost of reduced profit margin. Several different strategies can be adopted for extending the product life cycle before it goes into decline. Depending on the existing market scenario, one may choose any one or combination of the following strategies:

Fig. 2.2 Typical product life cycle and profit

26

2 Strategic Technology Development Process

● Advertising—try to gain a new audience or remind the current audience. ● Price reduction—more attractive to customers. ● Adding value—add new features to the current product, e.g., improving the specifications on a smartphone. ● Explore new markets—selling the product into new geographical areas or creating a newer version targeted at different segments. ● New packaging—brightening up old packaging or subtle changes. Adding value will often also need some innovation activities. Additional development cost may eat up the profit to a great extent. Hence, there is a need to understand the life cycle and a strategy around the same in order to utilize the full market potential. If it shows that just adding value will not be able to keep the product alive, then a strategy must be in place for developing next generation of the product or a new product in the market. This means that an early planning must be done with the full involvement of the top management. The timing for start of next product (2nd product) must start quite early in order to ensure that sales remain at top level at all times and the maturity of the 1st product’s lifetime is fully utilized (see Fig. 2.3) and extended period with considerable profit is also ensured. However, if due to some reason or other, the 2nd product development process starts late, it may so happen that sales revenue of the 1st product drops enough before even the 2nd product’s revenue starts to pick up (see Fig. 2.4). In extreme cases, it may work out to be catastrophic for the company concerned. The discussion above only strengthens the need for strategic innovation management plan with a well-thought-out product development and market introduction plan. With correct innovation strategy, a company can not only always remain ahead of the market but also can have a substantial revenue and profit margin and a considerable market share. This is a key to success for most companies.

Fig. 2.3 Extending product life cycle with 2nd product

2.4 Pricing Strategy

27

Fig. 2.4 Typical effect of delayed product development

2.4 Pricing Strategy Pricing is simply said as—‘the amount of money the company is asking the customer to pay to gain access to the product.’ Customers always have a limited amount of money, which they have to use wisely to maximize their benefits. Customers must be willing to pay the price set for a product in the market. Pricing is determined by value proposition, and how much a customer is willing to pay for the value the product is offering. Hence, a company must understand the dynamically evolving market and customer behavior and develop a pricing strategy that needs to be changed as the market arena evolves with time. Pricing strategy can be actively utilized as a tool for growing business. Some very common pricing strategies are: ● Value-based pricing—Here, the cost prices are calculated and then a markup is added to arrive at the selling price. ● Competitive pricing—Price is determined based on what the competitors are charging. ● Price skimming—A high price is set at the start and then slowly lowers the price as the market evolves. ● Value-based pricing—Pricing is based on what the customer considers the product is worth. ● Penetration pricing—The company sets a low price to enter a competitive market and raises the price later after the product has gained acceptance in the market. In order to create a winner pricing strategy, the company needs to: ● Study and understand the value proposition of the product. ● Understand the ‘Value metric’, i.e., what the company is charging for. ● Map ideal customer profile and segment.

28

2 Strategic Technology Development Process

● Portray the value of the product and communicate effectively to the customers. This is not an easy task. Communication is difficult and to ensure clear communication, customer’s perspective must be understood. ● Project a strong brand value, which can go long way to help securing customer confidence. Whatever may be the pricing strategy, the company must set up a business plan for approx. 3–5 years and sketch out how the revenue flow will take place. At the end of the day, a company must not only survive in the marketplace, but also grow with time. Hence, the selling price must be able to cover: ● ● ● ●

The cost prices The overheads Some profit to enable the shareholders to get return on their investments plus Some amount for the company to grow.

But how much profit the company can earn is determined by the willingness of the customers to pay for the values the product offered. By now, we have seen that ‘value proposition’ of the product and ‘communicating’ the same to the customers are important tools that will trigger the customers’ willingness to pay for the product.

2.5 Communication of Value Proposition Communication sounds simple but it is one of the most difficult tasks. People tend to hear what they want to hear and often filter out what they don’t want to hear! While communicating, it is of utmost importance to understand the listener’s perspective and his/her knowledge of the technology field. For an entrepreneur in a particular field, certain terminology or knowledge level may be too common to think that any other person listening will also be able to understand the same. Entrepreneurs often have very special knowledge and understanding of the product, which needs to be clearly communicated and checked with the listener that they really understand what is being communicated. Customers usually spend enough time on the Internet, researching products available in the market and trying to compare the products for their capabilities and price. An intelligent customer tends to buy the product which provides best possible facilities at best possible price (often cheapest). Naturally, to attract the customer it is important to highlight in what ways the product will satisfy the customer’s needs and why the product is unique and better than that of its competitors! A value proposition or Unique selling point identifies: ● The value offered to the clients/potential customers ● In what way the product offered serves the needs of the target customers ● In what ways the product is better than those of the competitors!

2.5 Communication of Value Proposition

29

This value proposition/unique selling points must be communicated to the potential customers in such a way that it is clearly understandable, and the potential customer feels the urge/inclination to buy the product and not another product from a competitor. In order to create an attractive value proposition, it is important to speak to the potential customer segment and understand their needs (what is most important) and philosophy of using the product. The value proposition should be clear, compelling, differentiating, and memorable, if possible. ‘Clear’ means the message is direct (unambiguous); identifies both the offering and the value or benefit. ‘Compelling’ means it conveys the benefits in such a manner that the potential customer feels an urge to buy the product. ‘Differentiating’ means it stands out as unique as compared to the products from the competitors. ‘Memorable’ means it will be hard for the customer to forget the unique selling points! It is a good practice to create groups of three important values of a product for the potential target customers. The values must be very clearly understandable and to the point. The values must NOT create any vague impression! Such groups of values need to be tested with representative customer groups and refined to make the values more attractive. A few examples of value propositions from some well-known companies: DNV—We are the world’s leading classification society and a recognized advisor for the maritime industry. We deliver world-renowned testing, certification, and technical advisory services to the energy value chain including renewables, oil and gas, and energy management. We are one of the world’s leading certification bodies, helping businesses assure the performance of their organizations, products, people, facilities, and supply chains. Accenture [1]—Our purpose: To deliver on the promise of technology and human ingenuity We help our clients become the next and best versions of themselves. Uber [2]—We reimagine the way the world moves for the better Pfizer [3]—Hope Changes Lives We’re in relentless pursuit of scientific breakthroughs and revolutionary medicines that will create a healthier world for everyone. Vimeo [4]—The World’s leading all-in-one video solution Equinor [5]—Our purpose is to turn natural resources into energy for people and progress for society. A customer usually pays for the value of the product and also the brand. While value generates satisfaction, a strong brand can generate both confidence and satisfaction.

30

2 Strategic Technology Development Process

2.6 Technology Strategy and Roadmap Technology strategy of a company encompasses all the tasks of building, maintaining, and exploiting a company’s technological assets. Technology foresight can help a company in predicting and preparing for the opportunities and challenges the new emerging technologies have to offer. Well-formulated corporate business and technology strategy play very important roles in a company’s success. Technology forecasting, technology assessment, and product planning are integrated by road mapping. Integrated technology road mapping provides a practical instrument for technology development and corporate business strategy formulation by aligning internal and external resources and other external market elements. Most successful companies usually have roadmaps that define the technologies they will pursue on a time scale. These technology roadmaps have to be linked to their product roadmaps to ensure successful execution of the innovation strategy. Technology roadmaps identify the place of the technology in the commercialization cycle, thus enabling the company to make decision for appropriate level of investment and resource allocation.

2.6.1 Creating Technology Roadmap As a business develops with time, not only the competition in the market also grows, but the technology trend also changes as new technology gets developed. To maintain its market share or increase the share, the company needs to adjust itself to the changing marketplace. The companies that can foresee the coming changes and adjust itself to the changing scenario are best suited to survive and flourish. To make these changes, which are necessary, the companies usually use a document called ‘Technology Roadmap.’ A technology roadmap lays out (often visual) new technology development intentions aligned with technology development trend and developing market need. This is a high-level document where rigorous assessment of implications and potential challenges involved in business operations must be addressed. Finally, this must be aligned with the company vision and strategy. A well-developed technology roadmap will be clearly understandable, with realistic milestones. A well-thought-out technology road map will enable a company to: ● Realign to ever-changing customer needs and preferences. ● Develop the right technological solutions at the right time to stay ahead of its competitors in the market. ● Increase productivity and profitability. ● Clearly communicate with its shareholders (who will approve any substantial investment in the development projects) as well as with the executives (who will have to execute the projects and get ready for taking the product to the market). ● Refocus management on boosting return on technology investment as per plan. ● Keep the team on track during execution process.

2.6 Technology Strategy and Roadmap

31

For creating a technology development roadmap for a company, the very first stage is to identify and agree on the strategic objectives, i.e., where the company would like to see itself in the market it is operating in in term of technological leadership. At this stage, one must also consider the current technology development landscape and trend of the core technology used by the company and decide which technology path will suit the company best. A technology roadmap is usually prepared by the top management, and its timely implementation also needs full support with resources from the top management. This is particularly important as any company must continue with its day-to-day business and roadmap has to be implemented without affecting the normal business activities. Understanding the audience is important, and this is why the roadmap must be laid out in easily understandable language for the top management and the stakeholders. A high-level technology development roadmap must be developed with clearly defined and realistic milestones. Once this roadmap is approved by the stakeholders, this needs to be translated into well-defined project plan and resources need to be allocated for timely execution of the plan for achieving the milestones. The top management must actively monitor the project portfolio management to both motivate and ensure timely execution as per plan. Figure 2.5 shows a typical visualization of technology development roadmap with milestones. Once the roadmap is approved and it is aligned with company’s vision and strategy, it is developed into project portfolio with several projects, each project delivering each of the milestones planned in the roadmap as shown in Fig. 2.6. A welldefined and meticulously planned project along with competent project management will help ensure efficient project execution as planned.

Fig. 2.5 Technology development roadmap with milestones

32

2 Strategic Technology Development Process

Fig. 2.6 Vision to roadmap to milestones

2.6.2 Defining the Problem/Challenge To find a solution to a problem/challenge, one needs to assign such work to a dedicated group of innovative people. But this means one needs to invest resources to do this. Therefore, often the management works out the potential of an innovation before they invest resources to find the solution. To start with any innovation process, we must answer the following questions first: ● How well is the problem/challenge/difficulty defined? ● Who is best placed to solve it? Well-defined problems/challenges can lead to breakthrough solutions [6]. When developing new products, processes, or even businesses, most companies aren’t sufficiently rigorous in defining the problems/challenges they’re attempting to solve and articulating why those issues are important for the solution. Without the rigorous approach in defining the problem/challenge, an organization may waste resources, incur failure, miss market opportunities, or end up pursuing innovation initiatives that are not aligned with the company strategy. Here is one example of a spectacular job of defining the problem [6]. This in turn attracted the right kind of innovators and led to breakthrough solutions. The Subarctic Oil Problem—More than 20 years after the 1989 Exxon Valdez oil spill, cleanup teams operating in subarctic waters still struggled because oil became so viscous at low temperatures that it was difficult to pump from barges to onshore collection stations. In its search for a solution, the Oil Spill Recovery Institute framed the problem as one of “materials viscosity” rather than “oil cleanup” and used language that was NOT specific to the petroleum industry. The goal was to attract novel suggestions from many fields. A chemist in the cement industry was awarded $20,000 for proposing a modification of commercially available construction equipment that would vibrate the frozen oil, keeping it fluid.

2.6 Technology Strategy and Roadmap

33

2.6.3 Disclosure of Invention In any organization, if an employee comes up with a new idea and if it is considered valuable for the company, a progressive management usually protects such ideas. When an employee has a good business idea, an invention, or other innovative ideas, it should be documented and registered internally using a form—a so-called DOFI (disclosure of invention), an example of which can be found in Appendix A. The management or the innovation department, if it has one, assesses whether the idea is good enough to proceed to the next step in the process, i.e., whether the idea should undergo an idea evaluation or whether it should be handled as a regular project initiative. This is also a document to show when the idea was first realized and by whom. Encouraging employees to come up with innovative ideas can often generate new opportunities. These new ideas/inventions can be valuable and should be treated as intellectual property (IP) generated by the individuals. Recognizing such contributions of individuals can contribute to creating a more innovative work environment.

2.6.4 Intellectual Property (IP) According to World Intellectual Property Organization (WIPO) [7], Intellectual property (IP) refers to creations of the mind, such as inventions; literary and artistic works; designs; and symbols, names, and images used in commerce. IP is protected in law by, for example, patents, copyright, and trademarks, which enable people to earn recognition or financial benefit from what they invent or create. By striking the right balance between the interests of innovators and the wider public interest, the IP system aims to foster an environment in which creativity and innovation can flourish. It is important to have a conscious approach so that new inventions, knowledge, etc., can be secured in the form of intellectual property (IP). IP is an asset, meaning it has a value and can be sold, licensed, or traded. IP is an intangible (not physical) asset and intellectual property rights (IPR) give the holder of the IP the exclusive right to exploit their intellectual property. In recent decades, IP has increased greatly as a percentage of global corporate assets and Intellectual property rights are an increasingly important part of the foundation for innovation and value creation. Internationalization in research, business, and technology means that such rights are under greater pressure and scrutiny than before. An overview of different forms of IPR is presented in Table 2.1. Intellectual property (IP) law allows owners, inventors, and creators of intellectual property to protect their intellectual property from unauthorized use by an outsider. IP may be protected against copying or other unfair use by competitors by utilizing the methods of trade secret, copyright, or a legal registration (patent, trademark, or design registration). Patents and design protect an inventor’s creation, while trademark protection safeguards distinctive words, names, symbols, sounds, and colors used to distinguish one

34

2 Strategic Technology Development Process

Table 2.1 Overview of different forms of IPR IPR

What can be protected

Duration

Patent

A patent can be obtained for technical products, methods, or applications if the invention is new, innovative, and useful The invention must constitute a practical solution to a problem, where the solution has a technical character and technical effect and is reproducible The invention must have an inventive step, i.e., the invention must differ substantially from the prior art in the field. It cannot just be a logical continuation of prior art Patenting an idea cannot be done without explaining or showing how it can be implemented in practice. Patenting a business concept is not possible in Europe

A patent gives the patent holder the exclusive right to use an invention for up to 20 years. For some inventions in the field of pharmaceuticals, the protection period can be extended by up to five and a half years, while for inventions in the field of plant protection, the protection period can be extended by up to five years

Trademark A trademark of a company differentiates the goods and services from others. A trademark may consist of words, names, logos, figures, images, letters, numbers, packaging, sound, or combinations thereof

A registered trademark is valid for 10 years and can be renewed for 10 years at a time thereafter without any time limit

Design

Design registration gives exclusive A design registration lasts for five years. rights to the appearance and shape of a It can be renewed for several periods for product. A prerequisite is that the up to a maximum of 25 years in total product has a new appearance that is not known from before the application for design registration is submitted

Copyright

The right to literary and artistic intellectual works, such as a piece of music, a book, a painting, applied art, a film, and computer program

Within the entire European Economic Area (EEA), such intellectual property is protected during the author’s lifetime and 70 years after the author’s death. If the work is a joint work, the term lasts for seventy years after the last surviving author’s death

business’s products and services from another. Property that qualifies for copyright protection includes literary works such as books and computer programs, and other artistic works. IP in the form of a patent can be very valuable asset, particularly for start-ups for attracting investors at an early phase of technology development. It gives the company an additional competitive edge. If a company decides to patent an invention, it is very important to keep the invention secret until the patent application is filed. The most common mistake an inventor makes is to publish the idea prematurely. If you reveal the idea before filing the patent application, you have in a way published

2.6 Technology Strategy and Roadmap

35

your invention and it may prevent you from obtaining a patent. For example, if your invention has been mentioned in previous patents, journals, or other literature (applies worldwide), or if you have presented it at an exhibition or during a lecture, or it has been mentioned in a local newspaper, brochure, or any word of mouth, it can ruin your chances of getting a patent.

2.6.5 Patenting Process If one decides to use patent as a means of protecting the intellectual property rights of the invention, one needs to understand the timeline for the patenting process starting from the date of submission of the patent application to the chosen Intellectual Property Office. During this process, it is of utmost importance that attention is paid to the deadlines assigned for handling the application. Figure 2.7 depicts a typical timeline for patent application. First patent application for an invention (the “priority application”) is usually filed in an applicant’s home country. This establishes a “priority date” for the invention. For the invention to be patentable, the invention must be novel and non-obvious over everything in the public domain before the priority date of the invention. Further patent applications, which are based on this priority application must be filed within 12 months of the priority date. This “priority year” allows time to develop the invention further, to seek investment, and to evaluate the market potential of the invention, before filing further patent applications. At the end of the priority year (12 months from the priority date), an international (PCT) patent application may be filed under PCT. The Patent Cooperation Treaty (PCT) is an international patent law treaty, signed on 19 June 1970, at the Washington Diplomatic Conference. The contracting states that are party to the PCT constitute the International Patent Cooperation Union. It provides a unified procedure for filing patent applications to protect inventions in each of its contracting states. A patent application filed under the PCT is called an international application, or PCT application.

Fig. 2.7 Patent application timeline

36

2 Strategic Technology Development Process

The text of this PCT application will be based on that of the priority application, together with any additional information on the invention which has been obtained in the priority year. In order to establish what relevant documents were in the public domain before the priority date, an International Search Report is produced by the International Searching Authority (usually the European Patent Office for applications filed within Europe). The International patent application will be published together with the International Search Report (if available then) at 18 months from the priority date. Within 30 months from the priority date, the applicant must file patent applications in their chosen countries (e.g., US, Europe, Japan, Australia, etc.). These will be examined independently by examiners from the patent offices of these countries, and (hopefully) patents in these countries will be granted in due course. At this stage, examinations of the application are independent of one another, although similar issues are likely to arise in different jurisdictions. Final grant of patent varies from country to country, but it usually takes 3–5 years from the priority date.

2.6.6 Patenting or Keeping Innovation Secret Patenting is time-consuming and expensive. But at the same time, a strong patent portfolio is important to give a company a winning edge in the market. If one decides to go for patenting, it is always advisable to use the competence of qualified patent attorneys, to ensure efficient formulation and handling of the application, until it is granted. A competent patent attorney understands and knows how broad a patent application can be formulated and at the same time knows realistic probability of success. Start-ups often try to save money either by trying to formulate patent applications themselves or by hiring patent attorneys who are less competent and hence tend to charge less. The net result of such money saving at this stage can result in rejection of patent application or delayed grant of the application. In either case, the final cost is much more, and one may miss the initial market opportunity. Large companies often invest across a broad technological landscape securing multiple patents and thereby creating a huge challenge for its competitors to find a way to navigate and secure some niche patents. Examples can be found in large mobile phone companies like Apple, Samsung, etc., who have thousands of patents worldwide. Such companies usually have allocated patent protection budgets aimed at future perceived portfolio value. However, for a start-up this can be quite challenging. Patenting is tricky but patent protection can be very hard and costly affair. Patent infringement happens all the time. Sometimes infringement happens unknowingly. But some companies also strategically go for patent infringement against smaller companies/start-ups. The legal costs can be prohibitive, and the start-ups can end up selling their patent at a cheap price. It must be appreciated that registering a patent in every market around the globe may be overkill and commercially unwise. By securing essential business hubs one can make it difficult for a competitor. Monitoring patent

2.6 Technology Strategy and Roadmap

37

activities of competitors can be very useful in understanding the market scenarios that the competitors are trying to exploit. Patents are suitable for solutions with qualities that allow them to be in the market for a long time, be of interest to many users, or to users with ability and willingness to pay. This can be a major challenge in a world where new technological platforms and solutions are developed and marketed at a fast pace. One should avoid patenting a technology which is expected to become obsolete in a few years. Understanding the trend of technology development in a particular field is important to decide whether to go for patent or not. An alternative strategy may be to keep the invention secret and constantly improve (alone or with partners) the invention in close cooperation with interested users and business partners so that the invention is always competitive in the market. A classic example is Coca-Cola. To keep its recipe a secret Coca-Cola has relied upon the use of contract law instead of traditional patent, to keep those who know the recipe from divulging. This is one of the best-kept secrets in the world. Another alternative may be to publish the invention to prevent others from patenting the same. This can be a very useful and economical tool to stop others from patenting. This strategy is often used in cases where a) it can be difficult to patent or b) it would not be profitable to patent.

2.6.7 Non-disclosure Agreement While developing new technology, one often needs to discuss the technology with potential business partners, production partners, collaborators, etc. In order to protect the in-house developed IP (even if it is not registered formally as patent or similar), it is highly recommended that a non-disclosure agreement (NDA) is signed by both the parties (i.e., the owner of the IP and the recipient of the information), before any discussion takes place about technological secrets with potential partners/collaborators or customers. NDA is a contract through which the parties agree not to disclose any information covered by the agreement. An NDA creates a confidential relationship between the parties, typically to protect any type of confidential and proprietary information or trade secrets. Like all contracts, they cannot be enforced if the contracted activities are illegal. NDAs are commonly signed when two companies, individuals, or other entities are considering doing business and need to exchange confidential technical/business information to assess a potential business relationship. NDAs can be “mutual”, meaning both parties are restricted in their use of the materials provided, or they can restrict the use of material by a single party. A typical mutual NDA is given in Appendix B.

38

2 Strategic Technology Development Process

2.6.8 Market/IPR Assessment Without establishing an understanding of product development need ahead of time, one could potentially waste precious time and money on unnecessary activities. Market research and assessment is an integral part of the product development process. It allows one to validate one’s ideas using data from the market and ensure that the product planned for development will be well accepted by the potential customers, compete within the market, hit the right price, right geographical location, target demographics, etc. Without conducting proper assessment, a product may not reach its fullest potential. A few important steps of market assessment are as follows: ● ● ● ● ● ● ● ●

Know the market, its size, and potential. Possible product life cycle. Know the competitors. Know the potential partners. Devise Unique Value Proposition of the product. Analyze the reasons as to why the product is commercially interesting. Any industry-specific requirements/regulations to be satisfied. Potential positive and negative societal and environmental impact. Preliminary assessment of commercialization path:

● Potential pathway for production ● Marketing ● Logistics and distribution. Taking a product to market starting from prototype phase is usually a big challenge for inventors, entrepreneurs, and enterprises. This has led to the concept of the innovation “valley of death”, which runs from the time the invention has been prototyped (technology readiness level 5/6) to the launching of the new product in the market (technology readiness level 9). The term technology readiness level is discussed in Chap. 3. This is the period where most inventions collapse due to the absence of sufficient finance or because they are not commercially viable. Securing funding during this phase is particularly crucial for start-ups or small entrepreneurs. During this stage, IP, particularly patents, play a crucial role in facilitating access to providers of early-stage capital, which may provide a lifeline to enable an invention to reach the marketplace. IP ownership strengthens the negotiating position when looking for investment partners and makes a business more attractive to potential investors. A well-managed IP portfolio, accompanied by a sound business plan and strategy that demonstrates how the associated IP rights can be exploited to generate future revenue, to develop a strong market position, and to control the market, is more than likely to attract venture capital.

2.7 Business Model and Business Model Canvas (BMC)

39

The mapping of similar solutions at the international level is a task that many don’t prioritize, with negative consequences for the company’s competitiveness. A systematic investigation that shows how far the current technology has come can be a source of inspiration for the project and can save the company development resources. There is no point in wasting resources if the technology has already been developed, even worse if already patented. In the mapping process, one can use online patent databases (http://ep.espacenet.com). With regard to the market, the mapping of relevant information can tell who is working on the issue (companies, universities, research institutions, etc.) and what market challenges the area is characterized by. This is how one can start with an early mapping of potential partners locally and internationally that can possibly contribute to, among other things, research and development, distribution, marketing, and sales. This can also be utilized for creating a good business model for commercialization of the product.

2.6.9 Time to Market In a situation when base technologies are widely available, new technologies are being developed at a fast pace and product life cycles are getting shorter, getting to market quickly is of prime importance. The company that is first to market often can command premium pricing because of its de facto monopoly. These early premiums are important since prices decline rapidly as soon as competitors arrive. With competitors in the market companies typically try to offset the price declines by improving production efficiency, but the resulting savings are not necessarily enough to compensate for sliding prices and to recover high development costs. Another way can be to add new features that can help gain the lost market share. Many managers fail to acknowledge the benefits of getting to the market first. The same managers who are very concerned about what an additional resource will cost and what profits will be lost if the company misses manufacturing cost targets seldom can quantify the losses associated with a delay in the development process. They often willingly slow down the development process to contain the project budget or to meet their cost targets. In this process, the company may lose the benefit of being first in the market.

2.7 Business Model and Business Model Canvas (BMC) Once an idea of the product/services to be developed is concluded and a preliminary market assessment has been done, it is time to create a business model. A business model is a structured framework for how a company will create value and generate

40

2 Strategic Technology Development Process

income. It identifies the products or services the company plans to sell, its identified target market, and any anticipated expenses. Business models are important for both new and established businesses. Businesses make assumptions about who their customers and competitors are, as well as about technology and their own strengths and weaknesses. Introducing a better business model into an existing market is the definition of a disruptive innovation, as written about by Clay Christensen [8]. One can say that an existing business model is failing when innovations yield smaller and smaller gains. One can innovate a new model by altering the mix of products and services, changing the people who make the decisions, or changing incentives in the value chain. One should not confuse business model with business strategy. Business model is all about how a company is creating value and getting compensated by the customer once they receive the product. Business strategy is all about how one plans on bringing the business to the market and how to execute the same. Now, let us focus on how to express the business model in a more visual manner. Business model canvas (BMC) is a visual strategic management document that will help one to define and communicate a business idea or concept quickly and easily. It shows a plan for the operation of the business, value proposition, sources for revenue, the target customer group, and revenue stream (Fig. 2.8).

Fig. 2.8 Business model canvas

2.7 Business Model and Business Model Canvas (BMC)

41

BMC has the following nine building blocks: 1. Customer segments—Who are the customers for whom we are creating value? 2. Value propositionWhat value is being delivered to the customers? Which problems/customer needs are our products going to solve? 3. Channels—How the product will reach the customers in a cost-effective manner? It can be own channels or through partners. 4. Customer relationship—How to get, keep the customers and then grow the customers? 5. Revenue streams—How will we get paid for the product/services? What strategy to use to capture the most value from the customers? 6. Key resources—This describes most important strategic assets. Typically, it can be any one or a combination of physical, intellectual, human, and financial resources. 7. Key activities—What are the most important strategic activities needed to be done to make the business model work? 8. Key partnerships—Identify the activities that are important but can be offloaded to partners. 9. Cost structure—Identify the key costs to ensure that they are aligned with value proposition and generate enough revenue. It is worth noting that the whole BMC is built around ‘Value proposition.’ The boxes on the right, i.e., Customer relationship, Customer segments, Channels, and Revenue streams are all related to customer, reaching the customer and revenue generation, while the boxes on the left, i.e., Key partners, Key activities, Key resources, and cost structure are related to creating value proposition and costs. For creating the BMC, the author would recommend starting with the value proposition. A few examples [9] of real-life Business model canvas are presented below for inspiration of the reader. Example #1. Amazon’s business model canvas is truly relevant in today’s growing e-commerce business environment (Fig. 2.9). Example #2. Airbnb offers online marketplace for renting places to stay at a local’s home or spare apartment. Both guests and hosts are customers for Airbnb (Fig. 2.10). Example # 3. Uber is world’s largest taxi company that does not own any taxi. This a very innovative business model (Fig. 2.11). A template for BMC can be found at Appendix C. This can be used as an extremely useful management tool that gives a total view of the business process.

42

Fig. 2.9 Business model canvas—Amazon

Fig. 2.10 Business model canvas—Airbnb

2 Strategic Technology Development Process

References

43

Fig. 2.11 Business model canvas—Uber

References 1. 2. 3. 4. 5. 6.

Accenture. [Internett]. https://www.accenture.com/no-en/about/company-index Uber. [Internett]. https://www.uber.com/us/en/careers/values/ Pfizer Inc. [Internett]. https://www.pfizer.com/ About Vimeo. [Internett]. https://vimeo.com/about About us. Equinor. [Internett]. https://www.equinor.com/about-us/equinor-in-brief Spradlin D. Harvard Bus Rev. [Internett]. https://hbr.org/2012/09/the-power-of-defining-theprob 7. WIPO. What is intellectual property? [Internett]. World Intellectual Property Organization. https://www.wipo.int/about-ip/en/ 8. Ovans A. What is a business model. Harvard Bus Rev. [Internett]. https://hbr.org/2015/01/whatis-a-business-model. 23 Jan 2015 9. 10 best business model canvas examples for your inspiration. Avada blog. [Internett]. https:// blog.avada.io/resources/business-model-canvas-examples.html

Chapter 3

Managing Technology Development

Abstract This chapter introduces the reader to technology development process and the terminology of Technology Readiness level. The importance of customer involvement from very early stage of technology development is discussed, and the term Customer Acceptance Level (CAL) is introduced. Any new technology development often starts with ideation of a technology, which further gets developed into concepts, which in turn is developed into prototypes and subsequently into a product after passing through a rigorous design and testing process. To make the technology ready for the market to be used by the customers, it undergoes a development process. During this process, the Technology Readiness Level (TRL) matures as it passes through various stages of development. Similarly, the customers are neither aware of the technology nor have any confidence in the technology at the very early stage of development. We call this as Customer acceptance level (CAL). Initially at TRL value 0, CAL is also zero. CAL value grows slowly as the customer awareness grows, and customer is engaged with the development process and gain confidence on the technology. The need for understanding the management of creative people is touched upon, and the need for a structured well-defined process for technology development is also discussed, to achieve fast-paced technology development process. This chapter discusses why concurrent engineering pioneered by NASA is preferred over traditional sequential design flow as in waterfall model used in technology development. Chinese way of industrializing innovation process is also touched upon very briefly. Keywords Technology readiness level (TRL) · Customer readiness level (CAL) · Concurrent engineering · Waterfall method · Accelerated innovation · Managing technology development

3.1 Technology Readiness Level (TRL) Technology maturity is often measured on a so-called Technology Readiness Level (TRL) scale. This scale says something about how far one has come in the development process and what documentation is available for the technology’s performance, and on what scale. © The Author(s), under exclusive license to Springer Nature Switzerland AG 2023 B. K. Datta, Fast-Track Innovation and Commercialization: Tools and Techniques, https://doi.org/10.1007/978-3-031-30375-3_3

45

46

3 Managing Technology Development

Table 3.1 Technology Readiness Level (TRL) Stage description

TRL

Idea only

TRL 0

Principles postulated and observed

TRL 1

Technology concept and application formulated

TRL 2

First laboratory test-proof of concept

TRL 3

Component tested and laboratory-scale prototype built

TRL 4

Protype tested in relevant environment

TRL 5

Prototype tested in intended environment and close to expected performance

TRL 6

System prototype demonstration in operational environment

TRL 7

Manufacturing issues resolved

TRL 8

Technology available for market

TRL 9

One can find different versions of TRL scale. In this book, we have adopted the TRL scale used by European Union [1]. Since any technology development activity in real world often starts with just an idea, we have used TRL scale from 0 to 9 to include this stage of IDEA only, in the development process (Table 3.1).

3.2 Customer Acceptance Level (CAL) To start with, usually customers are aware of the need of some better solution for their everyday work but carry on their daily routine anyway without expecting any new solution delivered to them. But if they are told that a better solution can be created at a reasonable cost for the customer, then they might feel interested. It is again telling a story of possibility of creation of a better and convenient solution for the customer. In this way, the customer can be engaged and acceptance of the possible innovative solution by the customer can be achieved. We have defined this as Customer Acceptance Level (CAL). The customer acceptance level and their engagement in the technology development process increase as the technology gets developed. Similar to TRL, we have tried to define Customer Acceptance Level (CAL) and various level of CAL is shown in Table 3.2.

3.3 Managing Creative People Technology development projects often pave the way to a new product line/new technological capability. Very often, it involves generating new technological knowledge and adaptation of a brand-new technology element into a new application. Although

3.3 Managing Creative People Table 3.2 Customer acceptance level (CAL)

47 Stage description

CAL

Idea—No R&D commitment—No customer engaged

0

Internal R&D commitment and customer is engaged

1

Internal resources commitment and customer is engaged 2 Customer awareness development

3

Customer’s active support

4

Customer’s commitment to pilot development

5

Customer’s active participation in pilot development

6

Customer’s commitment to utilize the technology

7

Operational benefit for customer

8

Impact on the market

9

it does not necessarily involve basic R&D, it often involves a lot of study and understanding technological challenges and finding ways and means of achieving the target results. Technology development projects are vital to a company’s long-term growth, prosperity, and sometimes even survival. Innovation needs open thinking and capability of embracing new thoughts and technologies almost every day. This needs a special breed of people. In these days of automation, new technology often involves a system made of mechanical, electrical/electronics, control system, and software. This can be achieved by collecting a group of brilliant engineering minds from each field and let them collaborate together in a team. Brilliant minds often tend to run after new challenges and new solutions. Although every organization claims to care about innovation, very few are willing to do what it takes to promote a creative work environment, keep their creative people happy, or at least, productive. Here are a few tips [2] on how to manage creative minds: ● ● ● ●

Let them play with their creative ideas. Involve them in meaningful work. Don’t pressurize them unnecessarily. Make them feel important.

Even when the innovative minds are collaborating in an excellent manner and producing the desired results, it does not mean that the creative minds can also take a leadership role! In fact, natural innovators are rarely gifted with leadership skills. There is a profile for good leaders and a profile for creative people, and they are rather different. Research indicates [2] that creative people can be rebellious, anti-social, self-centered, and often too low in empathy, to care about the welfare of others. But if they are managed well, their inventions can be delight for the others. They often don’t have social communication skills, but they thrive on creating new technologies.

48

3 Managing Technology Development

3.4 Why a Process is Needed It is quite common that in case of custom-designed and developed products, the requirement of the customer is channelized through the salesperson to the project manager and then down the line through the designer at various stages and then to the production people. Salesperson often hands over the information to the marketing people, who start marketing long before the final product takes shape! In such cases, people often come across funny situations as depicted (exaggerated) in Fig. 3.1. Variation of this cartoon [3] has circulated since the 1960’s. The cartoon shows how the information about the customer need is misinterpreted as the information passes through the various actors in the product development organization and how various people may misunderstand the customer need. Therefore, there is a need to structure the development process so that such awkward situations do not arise! The salespeople need to document thoroughly the requirement of the customers in unambiguous terms. This document must be handed over to the project team responsible for developing the product. The project team must study the document thoroughly before a kick-off meeting takes place with the customer, salespeople, and the project team participating. This meeting is very important and allows the project team to be on the same page with the salespeople and the customer. Any doubts must be clarified with the customer at the earliest opportunity.

Fig. 3.1 Why a process is needed

3.6 Industrializing Innovation Process—Chinese Way [8]

49

3.5 Concurrent Engineering and Its Benefits This section discusses why concurrent engineering pioneered by NASA is preferred over traditional sequential design flow as in waterfall model used in technology development. Concurrent engineering replaces the more traditional sequential design flow, or ‘Waterfall Model.’ In concurrent engineering, an iterative or integrated development method is used instead [4]. It decreases product development time and also the time to market, leading to improved productivity and reduced costs. The difference between these two methods is that the ‘Waterfall’ method moves in a linear fashion by starting with user requirements and sequentially moving forward to design, implementation, and additional steps until you have a finished product. In this design system, a design team would not look backwards or forwards from the step it is on to fix possible problems. In the case that something does go wrong, the design usually must be scrapped or heavily altered. On the other hand, the iterative design process is more cyclic in that, all aspects of the life cycle of the product are taken into account, allowing for a more evolutionary approach to design [5]. The difference between the two design processes can be seen graphically in Fig. 3.2. A significant part of the concurrent design method is that the individual engineer is given much more say in the overall design process due to the collaborative nature of concurrent engineering. Giving the designer ownership is claimed to improve the productivity of the employee and quality of the product that is being produced, based on the assumption that people who are given a sense of gratification and ownership over their work tend to work harder and design a more robust product, as opposed to an employee that is assigned a task with little say in the general process [6]. In the year 1993, a survey [7] was conducted in product development organizations in the USA. There was a broad representation of company size in terms of both revenue and number of employees. About 27% of the responding organizations were over 10 000 employees and 19% were above $1 billion in revenues. At the other end of the spectrum, 14% had less than 500 employees and 23% had less than $50 million in revenues. Reported benefits of concurrent engineering are shown in Table 3.3.

3.6 Industrializing Innovation Process—Chinese Way [8] The classic image of innovation, especially early-stage R&D, is of an inventor or a small team brainstorming and experimenting with new ideas. Large-scale and tightly defined processes are generally seen as inhospitable to creativity and innovation. Although innovation may be systematized and scaled up to involve thousands of scientists and engineers in some industries, such as pharmaceuticals and IT, the core R&D activities nonetheless typically revolve around a set (perhaps a large set) of relatively small teams. China has a huge resource pool of competent technicians and engineers. These technical resources are not necessarily exceptional, but they are cheap! In an effort

50

3 Managing Technology Development

Fig. 3.2 Traditional “Waterfall” versus Concurrent engineering method Table 3.3 Reported benefits of concurrent engineering

Items studied

Benefits

Development time

30–50% less

Engineering changes

60–95% less

Scrap and rework

75% reduction

Defects

30–85% fewer

Time to market

20–80% less

Field failure rate

60% less

Service life

100% increase

Overall quality

100–600% higher

Return on assets

20–120% higher

References

51

to accelerate innovation, they are utilizing this huge pool of resources in a very systematic and unprecedented manner. Like any good manager, they divide the task of innovation process into a large number of small bits and then assign teams to work on each bit. In this process, they have created a unique innovation assembly line that can deliver results quickly and, in a cost-effective manner. Chinese companies have opened up a new front of competition in the global market. It centers on what we call accelerated innovation — that is, reengineering research and development and innovation processes to make new product development dramatically faster and less costly. The new emphasis allows Chinese competitors to reduce the time it takes to bring innovative products and services to mainstream markets. Traditionally, new product and service development have been organized as a sequential “waterfall” [9, 10] process, where certain steps must be completed before subsequent stages could begin. NASA pioneered the approach of speeding things up by tackling certain steps in parallel. This approach is often referred to as “simultaneous” or “concurrent” engineering. The principle is quite simple in theory but in practice it demands much more open communication between teams and team members. Engineers are often unwilling to release information early, and it is not an easy task to coordinate a multidiscipline team. It takes time to build a smoothly functioning team cooperating and delivering in an optimal manner. Chinese companies, however, are not only practicing simultaneous engineering but have taken it to a new level. Let us consider the case of Lenovo Group Ltd. Lenovo acquired IBM’s personal computer business in 2005 and at that time its new product development cycle was approx. 12 to 18 months. Since the takeover, the company has focused on reducing the development cycle time and it has been brought down to almost half by applying simultaneous engineering across the entire innovation process, beginning in R&D and continuing through design, manufacturing engineering, quality control, procurement, marketing, and service. One leader supervises all the teams and its members who work on different elements in parallel.

References 1. Technology Readiness Level. HORIZON 2020—WORK PROGRAMME 2014–2015. [Internett] https://ec.europa.eu/research/participants/data/ref/h2020/wp/2014_2015/annexes/h2020wp1415-annex-g-trl_en.pdf 2. Chamorro-Premuzic T. Seven rules for managing creative-but-difficult people. Harvard Bus Rev. [Internett]. 2 April 2013 3. Behere S (2015) A systems engineering approach to design of complex systems. [Power point presentation] s.l.: Kungliga Tekniska H¨ogskolan, Stockholm 4. Ma Y, Chen G, Thimm G (2008) Paradigm shift: unified and associative feature-based concurrent engineering and collaborative engineering. J Intell Manuf 19:625–641 5. Concurrent Engineering. Wikepedia. [Internett]. https://en.wikipedia.org/wiki/Concurrent_e ngineering 6. Kusiak A. Concurrent engineering: automation, tools and techniques; John Wiley & Sons Inc., ISBN 0-471-55492-8 7. Karandikart ML, H M. A Survey of Concurrent Engineering. Concurrent Engineering: Research and Application. 2 1994, ss. 1–6.

52

3 Managing Technology Development

8. Yin, Peter J. Williamson and Eden. MIT Sloan Management Review. [Internett] http://sloanr eview.mit.edu/article/accelerated-innovation-the-new-challenge-from-china/. 9. Webpage, NASA. The Standard Waterfall Model for Systems Development. [Internett]. https://web.archive.org/web/20050310133243/http://asd-www.larc.nasa.gov/barkstrom/ public/The_Standard_Waterfall_Model_For_Systems_Development.htm 10. What is Waterfall model—advantages, disadvantages and when to use it? [Internett]. http:// istqbexamcertification.com/what-is-waterfall-model-advantages-disadvantages-and-when-touse-it/

Chapter 4

Systems Engineering Approach

Abstract This chapter introduces the reader to the concept of systems engineering management and the processes for managing an interdisciplinary approach for the development and realization of complex systems, which demand a high standard of lifetime performance. The principles of systems engineering management along with the process of development of system requirements are discussed. The importance of understanding the hierarchy of stake holders with example from oil sector industry is discussed. The process of concept development using function means analysis and Pugh matrix is shown using example. A typical concept development sheet is also presented. Further, the process of creating systems requirement document, requirement analysis and benefits of well-written systems requirement document is discussed. The structure of a typical system requirement document is also discussed and an example of such a document along with a template is presented in Appendix D—System Requirement Document and Appendix E—System Requirement Document template. The use and importance of requirement verification matrix, creating validation plan, system design document and technology development using systems engineering process is also discussed. A case study from Boeing showing benefits of using systems engineering process is presented. Keywords Systems engineering · Stake holders · Customer requirement · Operational requirement · Functional requirement · Performance requirement · Design requirement · Derived requirement · Concept development · Function means analysis · Pugh matrix · Concept development sheet · Systems requirement document · Requirements analysis · Requirement verification matrix · Validation requirement matrix · System design document

4.1 Systems Engineering Management INCOSE—International Council of Systems Engineering [1] defines Systems Engineering as follows: “Systems Engineering is a transdisciplinary and integrative approach to enable the successful realization, use, and retirement of engineered systems, using systems principles and concepts, and scientific, technological, and management methods.” © The Author(s), under exclusive license to Springer Nature Switzerland AG 2023 B. K. Datta, Fast-Track Innovation and Commercialization: Tools and Techniques, https://doi.org/10.1007/978-3-031-30375-3_4

53

54

4 Systems Engineering Approach

Simply said—Systems Engineering is an approach that focuses on the “big picture” and aims to define as well as achieve the desired functional, physical, and operational properties using requirements throughout the life of the system. Systems Engineering is a logical way of thinking. Systems engineers are at the heart of creating successful new systems. They are responsible for the system concept, architecture, and design. They analyze and manage complexity and risk. They decide how to measure whether the system works as intended. Systems engineering is the discipline that makes their success possible using their tools, techniques, methods, knowledge, standards, and principles. The launch of successful systems can invariably be traced to innovative and effective systems engineering. As illustrated in Fig. 4.1, systems engineering management is accomplished by integrating three major activities: ● Systems engineering process that provides a structure for solving design problems and tracking requirements flow through the design effort, ● Development process that controls the design process and provides baselines that coordinate design efforts, and ● Life cycle integration that involves customers in the design process and ensures that the system developed is viable throughout its life as per life cycle planning. Systems engineering process always starts with the ‘Big Picture.’ The big picture then undergoes a transformation process, and the ambiguities are transformed into ‘Discreet structures’ utilizing a process of trading of alternatives and arriving at

Fig. 4.1 Activities of Systems engineering management

4.2 The Development Process and System Requirements

55

optimal decisions. Process coordination at every step is key to success of this process and finally integration and successful systems validation. Any innovation using systems engineering approach will usually have the following characteristics: ● ● ● ● ● ● ●

Enhanced capability Adaptability Affordability Modularity Flexibility Testability Scalability.

4.2 The Development Process and System Requirements Let us try to understand how the technology development process plays out! A customer as shown in Fig. 4.2, wish to develop a system ‘A’ which is part of system ‘B’, which is in turn is placed in an environment ‘C’, with various stakeholders that will have influence of the systems design and performance. Let us give an example. Assume that the customer wants to develop an actuator to be used in a subsea X-mas tree, which is placed subsea on seabed. Subsea X-mas tree is the main equipment in off-shore oil and gas production. This is installed on the subsea well head and has all the equipment and control systems for controlling the flow of oil and gas from the subsea well to supply pipelines. The product to be developed must meet certain requirements in order to be used successfully. Before we

Fig. 4.2 Customer—stakeholder relationship

56

4 Systems Engineering Approach

proceed to look at the ‘Requirements,’ let us understand the stakeholders and their impact on the technology development. In a typical subsea product development scenario, the stakeholders will include the following: ● ● ● ● ● ● ● ● ●

The product developing company (supplier) The user System supplier The oil companies The sea users in and around the location of system under sea (fishing trawlers, shipping, etc.) Subsidiary companies that receive product from the system The local government Local communities Other related national and international bodies, etc.

Here is a need to understand the hierarchy of stakeholders, because at times hierarchy determines which requirement must be prioritized over the other. Figure 4.3 shows a typical hierarchy diagram often applicable to the above stakeholders. While the ‘USER’ and the subsidiary companies often demand ‘Functional Requirement,’ most of the stakeholders put additional demands to the system, which in turn works more as constraints! Let us now look at how the ‘Requirements’ are developed. There are two basic types of requirements: ● Operational requirements ● Functional requirements. Operational requirements often demand certain functional requirements. The equipment must perform certain functions under certain conditions. This is central to the whole technology development. However, there will be some non-functional requirements too. For example, it may demand that the equipment noise level must be under certain db. A further classification of non-functional requirements can be as follows: ● Non-functional Performance Requirements. For ex. Reliability, response time, security, etc. ● Non-functional System Requirements. For ex. User-friendliness, size, weight, etc. ● Non-functional Implementations Requirements. For ex. Regulatory compliance, legal compliance, etc. Figure 4.4 shows a typical set of requirements collected from stakeholders, which are used to formulate the functional requirements, while some non-functional requirements act as constraints.

4.2 The Development Process and System Requirements

57

Fig. 4.3 Typical stakeholder hierarchy

Fig. 4.4 Stakeholder requirements

4.2.1 Concept Development Once we have received the customer requirements, i.e., Stakeholder requirements and have understood what needs to be delivered, it is time to generate a concept, before moving into design phase. During this phase, the focus will be on:

58

4 Systems Engineering Approach

1. How many different ways we can achieve the customer requirements? 2. Selection of the best (optimum) concept with which to move forward into the design phase. This is a very important phase, and it needs to set up a team of creative brains (Design team) around the table. Such sessions must be planned in order to motivate each participant to give their best. The challenge to be solved must be laid out in front of everybody in a very understandable manner. Brain storming to generate ideas must be given sufficient time. It must be made clear that no idea is BAD idea, and the purpose of brain storming is to collect as many different ideas as possible and out-of-the-box thinking should be encouraged. No idea must be rejected at this stage even though it may sound useless/too simple/too complex. Before brainstorming for generation of several possible concepts, it is always recommended to set a baseline or base case. This will enable the team to find ways and means to achieve the target solution which will be better than base case.

4.2.2 Function Means Analysis Functional means analysis is a structured approach for generation and selection of system concepts by the creative design team. The process is based on identifying all the functionalities the system must perform and then noting down various possible means of achieving those functionalities. The resulting table will be used to show all potential system concept options simultaneously, making it easier to apply selection/deselection criteria to help generate whole system concept solutions. Table 4.1 shows an example of Function Means Table for a Room Heater system being developed. In this example, the left-hand side column lists the system functionality: the functionality that is deemed necessary to deliver the operational requirements of the system. The remainder of the table contains the potential means to achieve the functions listed in the left-hand side column. The functional solutions are identified/listed by the creative design team sitting around the table and through a brain storming session. The Function Means Table can be used to identify complete system solutions as shown in Table 4.2. In this instance, four potential whole system concept solutions have been identified by choosing one means for each function and then putting them in one group. Various lines (solid black line, solid gray line, lines with small dashes and longer dashes) are drawn passing through various cells, indicating selection of means. As shown by solid lines and dotted lines, a choice of 4 different system concept solutions is presented here. No 1 choice (solid black line): Wall-mounted heater—automatic switching system—digital thermometer—sensor mounted on heating elements and temperature limit switch on individual heating system.

4.2 The Development Process and System Requirements

59

Table 4.1 An example of function means table System: room heating system

date: dd/mm/yyyy

author:

Functions

Means

Heating

Standalone heater

Wall-mounted heater

Heating coil

Switching on/off

Individual switch

Automatic switching system

Control via mobile app

Display/user message

Wall-mounted thermometer

Digital thermometer

Audible message

Sense room temperature

Wall-mounted sensors

Sensor on A unit heating systems collecting temperature data from all sensors and calculating room temperature

Safety system Temperature limit switch on each heating system

Alarm on overheating

issue:

reviewed by:

Warm water pipe

Air conditioner

Display via mobile app

Central power supply trip when room overheated

Table 4.2 Function means table with potential solution System: Room heating system Functions Heating Switching on/off

Standalone heater Individual switch

Display/user message Sense room temperature

Wall mounted thermometer Wall mounted sensors

Safety system

Temperature limit switch on each heating system

Date:

Author:

Wall mounted heater Automatic switching system Digital thermometer Sensor on heating systems

Alarm on overheating

Issue: Means

Heating coil

Reviewed by: Warm water pipe

Air conditioner

Control via mobile app Audible message

Display via mobile app

A unit collecting temperature data from all sensors and calculating room temperature Central power supply trip when room overheated

No 2 choice (solid gray line): Warm water pipe—via mobile app—a unit collecting temperature data from all sensors and calculating room temperature—central power supply trips when room is overheated.

60

4 Systems Engineering Approach

No 3 choice (small, dashed line): Heating coil—control via mobile app—via mobile app—a unit collecting temperature data from all sensors and calculating room temperature—central power supply trips when room is overheated. No 4 choice (long dashed line): Air conditioner—via mobile app—a unit collecting temperature data from all sensors and calculating room temperature— central power supply trips when room is overheated. The identification of whole system concept solutions is usually preceded by some deselection of individual functional solutions as well as promotion of those clusters of functional solutions that benefit the system through their integration. As systems become more complex, it is no longer possible to create the complete system design in “one go.” Function Means Analysis allows a team (or individual) to generate and represent the “complete” solution space before any subsolutions are sought after. This permits the design process to be systematic, transparent, and traceable. Function Means Analysis allows us top-down design through the decomposition of system functionality. This starts with the identification of the system functions at the highest level. Once agreed solutions have been selected, Function Means Analysis is carried out again at a lower level of detail. As with most team-based tools, team size is important. There should be enough number of people to ensure a rich knowledge and experience base. Normally, a qualified systems engineer runs such process. Function Means Analysis has two distinct phases as shown in Fig. 4.5. The first phase employs divergent thinking to generate the potential functional solutions. The aim here is quantity rather than quality. The second phase employs convergent thinking to make sense out of the first stage by eliminating non-potential ideas and organizing the remaining ideas into complete or entire system concept solutions.

Fig. 4.5 The design philosophy of function means analysis

4.2 The Development Process and System Requirements

61

Pugh matrix The Pugh Matrix (after the name of Scottish scientist Dr. Stuart Pugh) is one of the most widely used methods for finding out the best solution, once a number of alternate solutions have been generated. The Pugh Matrix is very simple and is not at all mathematically intensive and at the same time it is fairly simple to use. Pugh Matrix is a criteria-based decision matrix that uses criteria scoring to determine which of the several potential alternatives should be selected. The Pugh Matrix also allows for simple sensitivity analysis to be performed, thereby providing some information as to the robustness of a particular decision. It is important to emphasize, however, that the quality of the outcome is very much dependent upon the experience of the team or individuals. Table 4.3 shows a typical completed Pugh Matrix that has been used to evaluate and select from a number of design alternatives. It shows a completed Pugh Matrix for four candidate design concepts called A, B, C, and D which can be found along the top of the matrix. These concepts have been evaluated against 10 criteria. In constructing a Pugh Matrix, one design concept, in this example “Design Concept A”, is selected as the “baseline.” This baseline is score as “S” against all of the criteria. The other candidate design concepts are then compared in a pairwise fashion against Design Concept A for each of the criteria. If a candidate design concept is: ● Better than the baseline a “+” is entered in the appropriate cell ● Worse than the baseline a “−” is entered in the appropriate cell ● The same than the baseline a “S” is entered in the appropriate cell.

Table 4.3 Example of a typical completed Pugh matrix Criteria No.

Design concept A

Design concept B

Design concept C

Design concept D

Design concept BC

Design concept BD

Criteria 1

S

+

S

+

+

+

Criteria 2

S

−

S

+

S

+

Criteria 3

S

S

S

+

S

+

Criteria 4

S

−

+

+

+

+

Criteria 5

S

−

+

+

+

+

Criteria 6

S

−

S

−

S

−

Criteria 7

S

+

S

−

+

+

Criteria 8

S

+

S

−

+

+

Criteria 9

S

−

S

−

S

−

Criteria 10

S

S

−

S

S

S

Total +

0

3

2

5

5

7

Total −

0

5

1

4

0

2

Total score

0

−2

1

1

5

5

62

4 Systems Engineering Approach

Table 4.4 Concept selection with weightage AC

Motor types Selection criteria

Weight

Rating

Total weight

Single DC

Double DC

Rating

Rating

Total weight

Total weight

Power

5

5

25

2

10

4

20

Weight

4

3

12

5

20

3

12

Complexity

2

3

6

5

10

3

6

Cost

2

3

6

4

8

3

6

Energy requirement

4

3

12

4

16

2

8

Efficiency

4

5

20

3

12

3

12

Total score

81

76

64

Rank

1

2

3

In Table 4.3, it can be seen that: ● Design Concept B is better than Design Concept A baseline for criteria 1. ● Design Concept B is worse than Design Concept A baseline for criteria 2. ● Design Concept B is the same as Design Concept A baseline for criteria 3 and so on. The overall evaluation is made by adding the “+” and “−” for each design concept. The Pugh Matrix can also be used to perform qualitative optimization by combining the candidate concept designs to form hybrid candidates. Table 4.3 shows two such hybrids “Concept BC” and “Concept BD”, which have got the highest total score. Quite often with a Pugh Matrix there is no clear “winner” but there is often a clear “loser” and also it allows to perform a sanity check (does the decision make sense) and remove the losing option. At this point, the criteria/requirements can be weighted to give better differentiation. Typically, the weighting is on a 1–5 scale with 1 the lowest and 5 the highest weighting. One such example is shown in Table 4.4. Outcome should also be “validated” by performing simple robustness assessments. The “engineering judgment” should be used to check if the outcomes “feel” right. Outcomes that are unexpected should be carefully reviewed as to why they have occurred. Like many other Systems Engineering tools, the Pugh Matrix is only a tool to help extract the knowledge and experience from the team. It is NOT an exact science and depends very much on the competence of the team members. The wrong team can still follow the process and arrive at a result—but the result may not be robust. Concept description sheet A Concept Description Sheet describes (in textual or graphical form) the technical approach, or the design concept selected and shows how the system will be integrated to meet the stakeholder requirements. A typical concept description sheet [2] for external missile guidance system is shown in Fig. 4.6.

4.2 The Development Process and System Requirements

63

Fig. 4.6 Typical concept description sheet

4.2.3 Process of Creating Systems Requirement Document The inputs to the process include the customer’s requirements and the project constraints. Requirements relate directly to the performance characteristics of the system being designed. It is related to the customer needs and objectives for the system throughout the system’s life cycle. It defines how the system will work in its intended environment. Constraints are conditions that exist because of limitations imposed by external interfaces, legal requirements, and international standards. Constraints put limitations on design opportunities. Requirements are the primary focus in the systems engineering process because the process’s primary purpose is to transform the requirements into designs. The process develops these designs within the constraints. They eventually must be verified to meet both the requirements and constraints. While writing the ‘Requirements,’ it is important to identify the following: 1. What or who performs the function. 2. Identify the verb! Functionality must be a verb. 3. Identify the measurable or variable about the functionality. While defining Systems Requirement Criteria, it is important to define Acceptance Criteria for the product/project also. Acceptance criteria (stakeholder requirement) for Apollo Project defined by President John F Kennedy [3] was: ● Put a man on the moon …—Functional requirement. ● Return him safely to earth …—Functional requirement. ● By the end of the decade (i.e., 31 Dec 1969)—Non-functional requirement (constraint).

64

4 Systems Engineering Approach

4.2.4 Requirements Analysis The first step of the Systems Engineering Process is to analyze the system/process inputs. System requirements are collected from various stakeholders (including customer) and sorted in a structured manner. Requirements analysis is used to develop functional and performance requirements; that is, customer requirements are translated into a set of requirements that define what the system must do and how well it must perform. The systems engineer must ensure that the requirements are understandable, unambiguous, comprehensive, complete, and concise. Requirements analysis must clarify and define functional requirements and design constraints. Functional requirements define what a product must do. They are mandatory in nature and are usually defined by the user. Design constraints define those factors that limit design flexibility, such as environmental conditions or limits; defense against internal or external threats; and contract, customer, or regulatory standards. Functions are analyzed by decomposing higher-level functions identified through requirements analysis into lower-level functions. The performance requirements associated with the higher level are allocated to lower functions. Higher functional requirements are broken down into lower subfunctional requirements. As all subfunctions meet their requirements, the functional requirement is also met. There are usually validated by design/analysis. The result is a description of the product or item in terms of what it does logically and in terms of the performance required. This description is often called the functional architecture of the product or item. Functional analysis and allocation allow for a better understanding of what the system must do, in what ways it can do it, and to some extent, the priorities and conflicts associated with lower-level functions. It provides information essential for optimizing physical solutions. Key tools in functional analysis and allocation are Functional Flow Block Diagrams, Timeline Analysis, and the Requirements Allocation Sheet. – Functional flow block diagrams define task sequences and relationships. – Timeline analyses define the time sequence of time critical functions. – Requirements allocation sheets identify allocated performance and establish traceability of performance requirements.

4.2.5 Types of Requirements Requirements are categorized in several ways. The following are common categorizations of requirements that relate to technical management: Customer Requirements: Statements of fact and assumptions that define the expectations of the system in terms of mission objectives, environment, constraints, and measures of effectiveness and suitability. Operational Requirements: This is the fundamental building block and must describe as to what the system fundamentally does together with the key constraints. Experience has shown that customers rarely specify Operational Requirements

4.2 The Development Process and System Requirements

65

because they believe it is obvious. They are not always obvious, and it is important to expend effort in developing Operational Requirements that all parties are happy with. The author will recommend that operations personnel from customer side be involved at this stage. It can bring in valuable insight for the project team. The Operational Requirements will demand certain system functionality that forms the basis of the Functional Requirements. Functional Requirements: The necessary task, action or activity that must be accomplished. Functional (what must be done) requirements identified in requirements analysis will be used as the top-level functions for functional analysis. Performance Requirements: During requirements analysis, performance (how well does it has to be done) requirements will be interactively developed across all identified functions based on system life cycle factors; and characterized in terms of the degree of certainty in their estimate, the degree of criticality to system success, and their relationship to other requirements. Design Requirements: The design requirements are usually derived from the functional and subfunctional requirements. The “build to,” “code to,” and “buy to” requirements for products and “how to execute” requirements for processes are expressed in technical data packages and technical manuals. Derived Requirements: these are the requirements that are implied or transformed from higher-level requirement. For example, a requirement for long range or highspeed transport vehicle may result in a design requirement for a relatively low weight construction. Attributes of Well-defined Requirements include the following: ● A requirement must be technically achievable (may be with some adaptation) using technologies available in the market and at the same time at affordable cost. ● It must be verifiable and is expressed in a manner that allows verification to be objective and preferably quantitative. ● A requirement must be unambiguous. It must have only one possible meaning. ● It must be expressed in terms of need, not solution. ● It must be consistent with other requirements. Conflicts must be resolved up front. ● It must be appropriate for the level of system hierarchy. It should not be too detailed that it constrains solutions for the current level of design. For example, detailed requirements relating to components would not normally be in a system-level specification. A well-written requirements document provides several specific benefits [4] to both the stakeholders and the technical team, as presented in Table 4.5. The systems requirement document is a live document during the whole product development process. Systems engineer normally takes care of the document and makes necessary adjustments of the requirements and at the same time ensures optimum design of the system. This is an iterative process and must be reviewed on a regular basis.

66

4 Systems Engineering Approach

Table 4.5 Benefits of well-written requirements Benefit

Rationale

Establish the basis for agreement between the The complete description of the functions to be stakeholders and the developers on what the performed by the product specified in the product is to do requirements will assist the potential users in determining if the product specified meets their needs or how the product must be modified to meet their needs. During system design, requirements are allocated to subsystems (e.g., hardware, software, and other major components of the system), people, or processes Reduce the development effort because less rework is required to address poorly written, missing, and misunderstood requirements

The technical requirements definition process activities force the relevant stakeholders to consider rigorously all of the requirements before design begins. Careful review of the requirements can reveal omissions, misunderstandings, and inconsistencies early in the development cycle when these problems are easier to correct thereby reducing costly redesign, remanufacture, recoding, and retesting in later life cycle phases

Provide a basis for estimating costs and schedules

The description of the product to be developed as given in the requirements is a realistic basis for estimating project costs and can be used to evaluate bids or price estimates

Provide a baseline for validation and verification

Organizations can develop their validation and verification plans much more productively from a good requirements document. Both system and subsystem test plans and procedures are generated from the requirements. As part of the development, the requirements document provides a baseline against which compliance can be measured. The requirements are also used to provide the stakeholders with a basis for acceptance of the system

Serve as a basis for enhancement

The requirements serve as a basis for later enhancement or alteration of the finished product

4.2.6 System Requirements Document For a real-life project, it is customary to create a ‘systems requirement document, which will remain a live document during the whole systems development project and until the product gets to commercial production. This document is used to specify the requirements for a system or subsystem and the methods to be used to ensure that each requirement has been met. The principles used in DI-IPSC-81431— System/Subsystem Specification [5], created by US department of defense are usually followed for creating systems requirement document. Depending on complexity of

4.2 The Development Process and System Requirements

67

the system to be developed, it is possible to use simpler version for less complex systems. The systems requirement document uses ‘Shall’ and ‘Should’ to express the various requirements: Shall—Expresses a mandatory provision. Should—Expresses non-mandatory provision. Will—Declaration of purpose such as a design goal, is used in the Design Document as described in System design document. A systems requirement document will usually have following sections: 1. 2. 3. 4. 5. 6. 7. 8.

Document definitions and explaining the ownership of mandatory provisions Documents finally generated and provided by the developer System requirements as defined by customer and stakeholders Applicable Industry standard documents Government documents Description of qualification methods Qualification matrix Verification cross-reference matrix.

Requirements are usually qualified by—(1) Analysis, (2) Visual Inspection, and (3) Test Tests can be at various levels of development. Tests can start at component level, followed by subassembly level, assembly level, and system Integration level. Verification cross-reference matrix works as a tool for requirements traceability. A systems engineer must monitor continuously the system requirements document during the development stage. Any change in specification during development can often have impact on other system requirements. Finally, after the design is complete and the product is developed, it undergoes some acceptance tests and the results of such tests must be acceptable to the customer, who then approves the product. Here are a few tips that’ll help write great acceptance criteria: ● Keep the criteria well defined so that any member of the project team understands the idea that is meant to be conveyed. ● Keep the criteria realistic and achievable. Define the minimum level of functionality that is possible to deliver and stick to it. On the other hand, avoid attempt to describe every detail since it may lead to cluttering up backlog and getting buried under many small tasks. ● Coordinate with all the stakeholders early in the project so that the acceptance criteria are based on consensus. ● Create measurable criteria that allows estimating adequately the development time, so that the project can be executed within budget and time constraints. ● Consider developing checklists to ensure user stories are covered with acceptance criteria. A typical system requirement document is given in Appendix D and one template for System Requirement document from ‘AcqNotes—Program Management Tools

68

4 Systems Engineering Approach

for Areospace’ (System Requirements Document (SRD)—AcqNotes) is given in Appendix E—System Requirement Document template.

4.2.7 Requirements Verification Matrix When developing requirements, it is important to identify an approach for verifying the requirements. This approach provides the matrix that defines how all the requirements are verified. Only “shall” requirements should be included in these matrices. The matrix should identify each “shall” by unique identifier and be definitive as to the source, i.e., document from which the requirement is taken. This matrix could be divided into multiple matrices (e.g., one per requirements document) to delineate sources of requirements depending on the project. All “shall” requirements shall be qualified by predetermined methods which can be: 1. 2. 3. 4. 5. 6.

Analysis Simulation Demonstration Inspection and review Test Any special method.

A typical example can be found at Sect. 5 ‘Verification’ in Appendix D. In a simplistic form, the requirement verification matrix could give an overview of the process as shown in Table 4.6. When developing requirements, it is important to identify a validation approach for how additional validation evaluation, testing, analysis, or other demonstrations will be performed to ensure customer/sponsor satisfaction. A typical validation matrix used by NASA [4] is shown in Table 4.7.

4.2.8 System Design Document The results of the system design process are recorded in the System Design Document (SDD) and usually describes the system and subsystem architecture, database design, human–machine interfaces, detailed design, processing logic, interfaces, etc., and refers back to the systems requirement, operating environment as described in the systems requirement specification document. It is a living document and evolves as the design progresses and finally frozen at the end of the product development process and is usually handed over to the customer at the end of the project.

Requirement code x

xxxx

ggggg

ttt

x

Not applicable

x

x

Inspection and review

yyy

x

Demonstration

eeee

vvv

zzzz

Analysis

Requirement description

Table 4.6 Requirement verification matrix

x

Similarity

Simulation

x

Test

4.2 The Development Process and System Requirements 69

Activity

Unique identifier Describe for validation evaluation by product customer/sponsor that will be performed

Validation Product #

Table 4.7 Validation requirement matrix

Validation Facility or lab method for the used for the System X validation requirement (analysis, inspection, demonstration or test)

What is to be accomplished by the customer evaluation

Performing organization

Phase in which the Organization validation will be responsible for performed coordinating the validation activity

Facilitator lab Phase

Validation method

Objective

Objective evidence that validation activity occurred

Results

70 4 Systems Engineering Approach

4.3 Technology Development Using Systems Engineering Process

71

4.3 Technology Development Using Systems Engineering Process Systems Engineering is an interdisciplinary approach for the development and realization of complex systems, which demand a high standard of lifetime performance. The aerospace and defense industries have been using systems engineering for a long time, and much of what they have learned is now being applied in other industries. Systems engineering is all about applying discipline to the system development process. 1. Technical discipline ensures that a sensible development process, from concept to production to final test and acceptance, is executed rigorously following a certain standard of quality. 2. Management discipline organizes the technical effort throughout the system life cycle, including facilitating collaboration, defining workflows, and deploying development tools. Developing smart products utilizing artificial intelligence and machine learning involves learning as you go, which creates changes throughout the process. To prevent stoppages and address the changes/learnings, the engineering process should be a continuous flow that allows for and even welcomes feedback, learning, and change. This process should enable Systems engineers, product engineers, and developers to: ● Integrate and analyze data that crosses the boundaries of traditional engineering disciplines such as software, mechanical, electronics, and others. ● Verify that the system is working appropriately before expensive physical products are built for testing. ● Run different types of analysis when traditional testing is not enough or time consuming or costly. ● Handle multiple requirements without compromising systems performance. Systems engineering tools help us in focusing on the real challenges. Let us try to visualize the process of technology development starting from the origin of the need to develop. Customers are usually the driving factors for developing new technology. Customer needs generate market opportunity and from there starts the journey of technology development. 1.

2.

Market opportunity and business strategy: If a company finds out a market opportunity and has a business strategy to exploit the opportunity, then the process of the product/technology development starts. Quite often the company does not have the needed competence and/ capacity to develop the product and hence engages a company capable of developing the product. Stakeholder Requirement: The first thing in this development process is to collect and organize:

72

4 Systems Engineering Approach

a. Customer requirements b. Other stakeholder requirements. At this stage, User Acceptance criteria is also defined. 3.

Concept Development: Next comes the concept development stage. Concept of operation and use cases are defined. Thereafter, a thorough exercise is carried out to choose the right concept. Here lies the foundation for a successful product/technology development down the line. 4. System requirements document: System requirements document is created and structured. This document will remain as a live document throughout the product development process. A System Design Document is also started at this stage. This also remains a live document throughout the project and is usually handed over to the customer at the end of the project. 5. System design and test plan: In this stage, the total system design is frozen in stages and the system test plan is developed in line with the system requirements document. At this stage, one needs to be very careful to identify the unknown factors and any unknown elements need to be tackled at the earliest opportunity to eliminate any risk of failure at a later stage of development. ‘Failure and Learning’ is the principle used in this phase for developing a robust solution. 6. Detail design: Following system design and subsystem design, we move on to the detail design. Interface engineering is extremely important function at this stage. Interface engineering takes care of any compatibility issues and challenges that might occur at the time of assembly. 7. Production: Following detail design, starts the production of components, hardware (HW) and software (SW). Some SW development can start quite early also. 8. Component testing: Components are checked and tested, if needed, for ensuring quality of production. 9. Subsystem assembly—Components are assembled and tested for quality and functionality. 10. System integration—In the next stage, all subsystems are assembled, and system integrity is ensured. At this stage, system functional tests are also done to check if the system is functioning as designed. 11. System validationIn this stage, the whole systems is validated against the system requirements. Once this is done, the customer is invited to witness customer acceptance tests. 12. Customer acceptance tests in principle demonstrates that the product meets the essential customer requirements and stakeholder requirements. At this stage, it is signed off usually and customer takes over the product for commercial production and sale. All these above activities are shown in Fig. 4.7 in the form a traditional V model, systems engineering process diagram.

4.4 Impact of Systems Engineering on Quality and Schedule—A Case Study

73

Fig. 4.7 Systems engineering process diagram (V model)

4.4 Impact of Systems Engineering on Quality and Schedule—A Case Study A unique opportunity occurred at Boeing as reported [6], in which three roughly similar systems were built at the same time using different levels of systems engineering. The three systems were Universal Holding Fixtures (UHF), used for manipulating large assemblies during the manufacture of airplanes. Each UHF was of a size on the order of 10 ft × 40 ft, with accuracy on the order of thousands of an inch. The three varied in their complexity, with differences in the numbers and types of sensors and interfaces. The three projects also varied in their use of explicit SE practices. In general, the more complex UHF also used more rigorous SE practices. Some differences in process, for example, included the approach to stating and managing requirements, the approach to subcontract technical control, the types of design reviews, the integration methods, and the form of acceptance testing. The primary differences noted in the results were in the subjective quality of work and the development time. Even in the face of greater complexity, the study showed that the use of more rigorous SE practices reduced the durations. (a) From requirements to subcontract Request for Proposal (RFP) (b) From design to production (c) Overall development time. Figure 4.8 shows the significant reduction in overall development time. It should be noted that UHF3 was the most complex system and UHF1 the least complex system. Even though it was the most complex system, UHF3 (with better SE) completed in less than 1/2 the time of UHF1. Quantitative results on return-on-investment (ROI) of

74

4 Systems Engineering Approach

Fig. 4.8 Overall development time for the projects [7]

Systems Engineering has been studied from an analysis of the 161 software projects and the authors concluded [8] that larger projects enjoyed larger Systems engineering ROI values as compared to smaller projects.

References 1. Systems Engineering—INCOSE. INCOSE. [Internett]. https://www.incose.org/systems-engine ering 2. Systems Management College, Department of Defense. Systems Engineering Fundamentals. [Internett]. Jan 2001. https://ocw.mit.edu/courses/16-885j-aircraft-systems-engineeringfall-2005/6128a102c1a9b6dbd30f2fb18c12aa64_sefguide_01_01.pdf 3. Kennedy JF (1962) Address at Rice University on the Nation’s Space Effort. Houston, Texas, United states of America 4. NASA (2016) NASA Systems Engineering Handbook rev 2. [Internett]. file:///E:/Innovation1/Manuscript_oldfolder/systems%20engineering/NASA%20Systems %20Engineering%20Handbook%20rev%202.pdf. NASA SP-2016-6105 Rev2. 5. U. S Department of Defense. DI-IPSC-81431—System/subsystem specification (SSS. Systems Engineering Goldmine. [Internett]. https://stagingseg.ppi-int.com/node/44808. DI-IPSC-81431. Sitert: 18 Oct 2022 6. The Impact of Systems Engineering on Quality and Schedule—Empirical Evidence. Frantz, W.F. St. Louis, MO: s.n., 1995. NCOSE International Symposium 7. Honour EC (2004) Understanding the value of systems engineering. s.l.: LAI Consortium 8. Boehm B and Valerdi R (2007) The ROI of systems engineering: some quantitative results. In: INCOSE international symposium; IEEE international conference on exploring quantifiable IT yields. IEEE, Netherlands. Print ISBN: 978-0-7695-3851-8

Chapter 5

Systems Engineering Best Practice and Useful Tools

Abstract This chapter describes the best practices used by the author for executing several multidiscipline complex technology development projects successfully, while he was working at Kongsberg Devotek at Kongsberg in Norway. The process has been cultivated and further developed at Kongsberg Devotek, which has been a part of the CoE (Centre of Excellence) for Systems Engineering in Norway. The importance of early testing of unknown technological elements is stressed, and extensive use of digital tools, dynamic simulation, animation, and 3d printing is recommended. The processes used in qualification of new technology are touched upon. Use of A3 as a decision-making tool is discussed. The importance of risk management is discussed, and use of Risk Register is introduced. A sample risk register is also presented in Appendix G—Risk Register. A fast track technology development process is presented graphically with CAL and TRL as the two axes. The importance of practice of LEAN philosophy in technology development process and cycle of knowledge creation is discussed. Finally, some challenges associated with such processes are mentioned. Keywords Best practice · Design for manufacture (DFM) · Qualification of technology · HAZID · HAZOP · FMECA · FTA · SWIFT · OPERA · Root cause analysis · Risk management · Lean process · Cycle of knowledge creation · Fast track innovation · Freedom to operate · Unique selling proposition · Licensing

5.1 Systems Engineering Best Practice The benefits of combining Systems engineering with Concurrent engineering can be huge. Combining concurrent engineering in the early phase of system concept and system design can eliminate lots of risks of failure at a later stage. A few important aspects that need to be taken good care of are listed below: ● ● ● ●

Define the desired end result/product along with the stakeholders. Define the problem with success criteria in the form of system requirements. Don’t assume one solution. Keep an open mind to examine several alternatives. Break down the problem in several small manageable bits (subsystems).

© The Author(s), under exclusive license to Springer Nature Switzerland AG 2023 B. K. Datta, Fast-Track Innovation and Commercialization: Tools and Techniques, https://doi.org/10.1007/978-3-031-30375-3_5

75

76

5 Systems Engineering Best Practice and Useful Tools

● Run parallel iterative concept development for the subsystems with very earlystage model testing to eliminate any uncertainties/risk. ● Learn as much as possible through failed early testing. ● In case of large projects over several years, delay the specific technology choices by a reasonable time limit. This is to ensure that the product utilizes the latest and best technology available at the time of delivery. ● Make design decisions always linked to system requirements. When it has been decided which concept is to be developed, one must think carefully about which parts of the concept are known from before and which are unknown. This is in a way a risk assessment of the whole concept and should be done carefully with others to identify any possible weaknesses. One needs to think carefully about where the weaknesses might be! Risk management is discussed further in Sect. 5.2. It must be defined already in the specification of the development phase which functionalities are absolutely necessary for the innovation to be a success. Unknown (uncertain) elements in the concept must be handled/resolved at an early stage to eliminate uncertainty in the development process. “Proof of concept” must be in place before proceeding with detailed design, development, testing of a prototype, and later a demonstrator. Figure 5.1 depicts the best practices followed by the experts in systems engineering (the collaboration partners of the author) who has successfully developed many complex multidiscipline systems over the years at a very fast pace and at reasonably low cost, considering the complexity of the systems developed. Tracing the V-model from left to right one executes the system engineering process in a series of steps: Business strategy: One starts with the technology development vision to address a market segment’s requirement.

Fig. 5.1 Systems engineering best practice

5.1 Systems Engineering Best Practice

77

Stakeholder Requirement: Stakeholders are involved at a very early stage to gain an understanding of what will be needed to achieve in order to get acceptance by the targeted market segment. Once the stakeholder requirements are outlined, one can start looking at possible system concepts. Substantial time needs to be allocated to identify possible concepts, before selecting a potential concept. Once the chosen concept(s) are identified, the work on developing the system requirements document starts along with systems requirement analysis. The work on system design also starts, and a system design document is also developed. The work on systems requirement document and system design work goes on in an iterative process until a satisfactory system design is arrived at. Use of animation and 3d model in digital (as well as 3D printing) form can be very useful tool at this stage for understanding and for communicating with all project members including the main stakeholders. Early testing of subsystems and learning from any failure as early as possible in the system development phase is a key to success. During this phase, focus is always on identifying unknown elements that needs to be understood. To understand the functioning of any proposed mechanism and to identify any possible clash with components during its assembly or operation, it may be very convenient to use 3D print, 3D models (digital), 3D animation, etc. Simulation of dynamic behavior and performance should also be extensively used as a complementary method to 3D prints. Often challenges are more easily visible when such visualization techniques are utilized. This can help in visualizing/understanding the possibilities/limitations of concepts of systems/subsystems. Equally important is to recognize the importance of Control algorithm and SW, which must also be tested at prototype level before implementation. Once the system design is frozen, one goes into the phase of subsystem design. In this phase, also iterations are made to refine the system requirements and use of 3D prints/animations are made to understand the success potential of the subsystems. System test plan is also worked out at this stage which will also include testing of subsystems. System qualification and acceptance test plan is also detailed out with respect to system requirement and stakeholder requirements. By this time, most of the risks associated with unknown elements are identified/tested with 3D prints or models/analysis. Once the risks are understood well, mitigation actions are also comparatively manageable. Detail design: In this stage, it is supposed to be quite straightforward, but usually this is the stage when surprises start popping up from various sections. It can so happen in extreme cases that it is not possible to carry out the tasks as per subsystem specifications! Hence, there must be an established feedback loop to toplevel systems specification, system design, and interface management system, to tackle and incorporate any alternative design solution(s). The author would like to stress the importance of competent design engineers with good knowledge of material properties and knowledge of various opportunities available with different production techniques. With a competent design engineer on the team, it will be often possible to find a way to produce components cheaper and

78

5 Systems Engineering Best Practice and Useful Tools

faster. Many a time designers can make a wrong choice of material and/or production technique which can lead to complex and costly production of components. With 3D print getting easily available with various materials of construction, in near future manufacturing using 3D printing technology could become normal practice or cheaper option. Design for manufacture (DFM) plays a critical role in any product development process. Including potential manufacturers in the development process and getting their unique insight into the production techniques and challenges, one may be able to optimize the design so that it is possible to manufacture at the lowest cost. DFM has been effectively used for addressing product pricing pressure from the market. Managing interfaces between various units and subunits need to be given due importance, to avoid any surprises during assembly and system integration phase. The aspect of maintenance and accessibility for maintenance of the system during its total life cycle must also be given due weightage while designing. Production of components: This includes production of all types of components, i.e., mechanical, electrical, electronics, and software. Each component must be manufactured according to the design specification developed. Each of these production processes has their own system for maintaining track of production process control and version control. Component Verification: Testing of each component-level hardware is done for verifying its functionality against the appropriate component-level requirements. Subsystem assembly and testing: Assembly of subsystems is carried out and tested for verifying each subsystem against corresponding requirements as set out in the systems requirement document. System integration and function testing: Assembly of the subsystems and subsequently the complete system is tested against system requirements. Verification is done so that all interfaces have been properly implemented, and all requirements and constraints have been satisfied. This method as described above has been used in several multidiscipline technology development projects with huge success. In this process of development and learning, design becomes more fool proof and robust. The system design and testing go much faster without any major challenges.

5.1.1 Qualification of New Technology The process of technology qualification creates evidence that the technology will function as desired within the specified operational limits and with an acceptable level of confidence. For recommended practice for Qualification of New Technology, the document DNV-RP-A203 may be referred to. This recommended practice is especially useful where failure poses high risk to life, property and/or the environment or alternatively has an inherent threat of high financial risk. In technology qualification that may pose significant threat (to life, financial, environment, etc.), it is

5.1 Systems Engineering Best Practice

79

often practice getting a third party to certify the qualification processes/tests. Thirdparty certification means that an independent qualified organization has reviewed the process/technology and has independently determined that the final product complies with specific standards for safety, quality, or performance. Typical companies for such third-party inspection and certification can be DNV GL, Bureau Veritas, DEKRA, Lloyd’s register, SGS, etc. Such qualification of new technology will often involve: ● Hazard identification—Also known as HAZID. It involves a process of identifying high level of hazard identification, usually for a complex process. It is usually carried out as a workshop, involving a panel of experts covering the necessary fields of competence and experience. ● Threat assessment—The objective of this process is to identify relevant failure modes with underlying failure mechanisms for the elements of the new technology and assess the associated risks. Threat assessments methods to be used can be (a) (b) (c) (d) (e)

Failure Mode, Effect and Criticality Analysis (FMECA) Hazard and Operability study (HAZOP) Fault Tree Analysis (FTA) Structured what-if checklist (SWIFT) Operational Problem Analysis (OPERA), etc.

The members participating in the above processes shall be identified in the technology qualification program and their respective expertise documented. The expertise should also cover regulatory requirements for the technology in its intended use.

5.1.2 Decision Making Tool A good decision-making tool that is very popular with systems engineers is A3 thinking process. The A3 process is a problem-solving tool Toyota developed to foster learning, collaboration, and personal growth in employees. The term “A3” is derived from the particular size of paper used to outline ideas, plans, and goals throughout the A3 process. The A3 report is a one-page document shown in Fig. 5.2. It can be found also as template in Appendix F. It typically contains 5–7 sections that systematically lead you toward a solution. 1. Background/Clarify the problem: Explain the problem in a few sentences, including its context. 2. Break down the problem: Explain the current problem. One can use process mapping to see the different tasks that surround the issue. This isn’t essential, but it will make it easier to locate the root cause.

80 A3 No. and Name

5 Systems Engineering Best Practice and Useful Tools Team members (name & role) 1. 2.

Team Leader (name & 'phone ext)

3. 4.

1. Clarify the problem

Stakeholders (name & role)

Department

Organisation objective

1. 2.

3.

Start date & planned duration

4.

7. Monitor Results & Process

4. Analyse the Root Cause

2. Breakdown the problem

8. Standardise & Share Success

5. Develop Countermeasures Countermeasure

Impact on target

6. Implement Countermeasure 3. Set the Goals 1 2 3 4

Fig. 5.2 A3 template for problem-solving

3. Goals: Define the desired outcome and include matrix for measuring success. One won’t know everything until the end is reached. Hence, one may need to come back and refine/revisit stages 1–3. 4. Root cause analysis: This is a big stage of the process. You need to work out what you think the root problem is. Several methods can be used here. However, the author has good experience in using 5 whys. A typical example of using 5 whys is shown in Fig. 5.3. 5. Countermeasures: Once the root cause is identified, one can start proposing solutions. 6. Implementation: Work out how to implement these solutions, including an action list with clearly defined roles and responsibilities. Any tool that can help everyone on the team track each other’s progress in real-time will be useful here. 7. Follow-up: Using matrix for success, it should be possible to decide whether the problem was solved. Results are to be reported back to the team/organization. In the spirit of Lean (continuous improvement), one should go back and modify the plan if the results weren’t as expected. And if they were, one should make this process the new standard.

5.2 Risk Management Multidiscipline technology development often takes a detour through the complex process of innovation. Such innovation, although not a pure R&D activity, is often a very complex process, and it is not very straightforward to predict the outcome. A

5.2 Risk Management

81

Fig. 5.3 5 whys method illustration

project manager of such multidiscipline projects has a challenging task of motivating a group of highly creative engineers/scientists and at the same time has to respect the timeline and the budget provided by the stakeholders. Any delay in delivery usually is accompanied by a cost over-run and at the same time can lead to missed opportunity in the market. Since these projects are developing something new, these are usually associated with lots of unknowns and these unknowns pose threat of risk. Hence, risk management plays a central role in such technology development projects. The principle for the process of risk management is outlined in ISO standard for Risk management Guidelines ISO 31000:2018. Following this principle, a Risk Register is usually established early in the project to capture and maintain information on all the identified risks/threats and opportunities relating to the project [1]. The following various risk categories should be considered: 1. 2. 3. 4. 5.

Technical External Project organizational Management User

The likelihood of risk occurrence, i.e., probability(P) along with the impact (I) of the risk on the project outcome, must be taken into consideration. Multiplying P and I gives a score which is used to create a P–I diagram. A typical P–I diagram is shown in Fig. 5.4.

82

5 Systems Engineering Best Practice and Useful Tools

Fig. 5.4 Typical P–I diagram

Risk assessment should be performed at the start of a new project phase and must be updated continuously. A continuous conscious monitoring needs to be done, and one should always look for any indicator for risk to arise or any risk that has occurred. Once the risk is identified, the project must decide how to handle the risk, i.e., (a) (b) (c) (d)

Is it possible to avoid the risk? Is it possible to transfer the risk to a later stage? Is it possible to mitigate the risk? Is it possible to accept the risk and move on without having huge impact on the project?

Mitigation plan will be incorporated in project management plan and followed up during the project. At the start of the project, after first risk assessment, it is normal to expect a lot of red cells in the P–I diagram and few green cells. By the end of the project, ideally one should expect to see no red cells in the P–I diagram. A typical Risk Register template is given in Appendix G.

5.3 Fast Track Technology Development Process In an ideal situation, we want to have a potential end customer with us who is interested in the product/service from a very early stage of the development process. An engaged and committed end customer will be a confirmation that there is a market and that the market is interested in the end product. At the same time, engagement of a committed customer from early stage will ensure that the requirement specification document is well developed, and all the customer needs are addressed in the new solution. An ideal fast track technology development process run is shown in Fig. 5.5 and shows the relationship between the development of TRL (technology readiness level) and CAL (customer acceptance level). In an ideal situation, the development process goes without much deviation from the line of shortest path (along the 45° line) and the product is ready for commercial exploitation in the shortest possible

5.4 Lean Process in Technology Development

83

Fig. 5.5 Ideal fast track development process

time. The customer is engaged in the development process from day 1, and hence, it is possible to capture all the important requirements from a customer’s point of view. The customer in a way represents the pilot client who will test the product and take the product to the market. Developing a product can be relatively easy to achieve but getting entry into the marketplace and secure a market share requires a lot of work. One need to build up a winning team with several partners as identified in the BMC.

5.4 Lean Process in Technology Development The fundamental of a LEAN process is to avoid any wastage/anything that is redundant/anything that does not contribute to learning process, and as a result, the process progresses much faster and the end result is achieved without unnecessary delay.

84

5 Systems Engineering Best Practice and Useful Tools

In any new technology development project, there are often many unknown factors. Starting from knowing the customer and their needs to developing new technology is a continuous learning process and is NOT a straightforward Standard Project Management. In a standard project, the activities are more or less of repeat nature and the people involved have already developed skills either during their education or later as a trainee. Apart from high level of technical competence, a very important set of skills needed for the technology development project team are: ● ● ● ●

They must be curious Ready to learn Willing to take calculated risks to solve technical challenges Must be ready to think NEW!

The author has witnessed examples where large corporations had to go back to the design board after their final prototype failed. These things often happen if the product development process has NOT followed a structured approach. Often not enough time is spent in ● Developing the system requirements document thoroughly ● Reaching a good viable concept. These two are very fundamental in any technology development project. At the same time, Systems Engineering document must not go to such detail level that they hinder flexibility in finding optimal solution. Project meetings can be unproductive if it does not have any clear purpose or does not result in any clear decision or action. The decision-making process can also be very unproductive if a structured method is not followed. The author has a very good experience with A3 as a decision-making tool and will highly recommend its use. When we keep on eliminating the waste processes in a technology development project organization, all members tend to get more time and energy to do the tasks that matter most to them, i.e., new technology development. As a result, they gain more knowledge and skills; they tend to develop competence to eliminate risks/mitigate risks in a more efficient manner. Consequently, the end product is much better and reaches the market much faster. It sets off a cycle of events depicted in Fig. 5.6. By reaching the market faster, the customer gets large market share and hence the customer is happy. A happy customer will come back/recommend for future technology development projects, and thus, the cycle goes on.

5.5 Some Challenges Like any process, this also comes with a series of challenges. Exchange of information, keeping a close eye on system and stakeholder’s requirement, and documented and structured decision-making process are some of the major challenges. To make the development manageable, one needs to break the challenges down to small manageable pieces. Lots of effort should be given to the concept development

5.5 Some Challenges

85

Fig. 5.6 Cycle of knowledge creation

phase, and several concepts should be evaluated carefully in a structured manner before they are discarded. Systems engineering is very important in any technology development program in early phase of development, when influencing the design incurs less cost and design changes can be made easily. In any development project, to start with there will be a lot of uncertainties and unknown technological challenges and consequently the risks are very high. As the project progresses through concept freeze and top-level design is concluded, the risk gets substantially lowered. In the detailed design phase, all the problems are usually resolved and naturally risk gets further less and less. On the other hand, if lots of effort are put on systems engineering the cost of activities related to systems engineering will increase. One needs to find a balance between the risk minimization and the cost of implementing systems engineering. A typical Risk-Cost relationship is shown in Fig. 5.7. A close control on the system requirements specification throughout the technology development process is extremely important for success. Describing the process sounds quite simple but deciding as to what extent effort should be used in creating new concepts remains very subjective. Skilled professionals with adequate technical competence and system engineering capability can make big difference in making right decisions. Quality of Systems engineering efforts can also make a huge difference. The decision-making process at every stage is very critical and needs to be well documented and traceable. INCOSE data shows [2] that a spending of approx. 8% (much less than what one spends on fixing mistakes/errors at a later stage) of total project cost on Systems engineering can reduce average cost of project by approx. 20% or more! This also increases likelihood of completing the project on time. The author suggests using a rule of thumb of using 10–15% of total project

86

5 Systems Engineering Best Practice and Useful Tools

Fig. 5.7 Risk-cost relationship with degree of systems engineering process

cost on Systems engineering. A technical report [3] on Value of Systems Engineering refers to research finding that ‘Optimum value of systems engineering is about 15% of a total development program’.

References 1. Office of Government Commerce, UK (2009) Managing successful projects with PRINCE2. s.l.: TSO, Ireland. ISBN: 9780113310593 2. Sonntag C. Systems engineering bootcamp. [Internett]. http://www.syseng.co.za/ 3. Honour EC, Axelband E, Rhodes, Donna H (2004) Technical report value of systems engineering. s.l.: INCOSE Systems Engineering Center of Excellence

Chapter 6

Key to Successful Fast Track Innovation

Abstract This chapter summarizes the whole process of innovation of a new product/process and the key factors influencing the success/failure. Starting from the concept phase, it is time to take a look at the whole process and try to understand the key factors that can lead to successful fast track innovation. Now that the whole process of innovation has been discussed, the authors would like to discuss briefly about commercialization, different pathways for commercialization, and its importance for a successful entrepreneur. Finally, some words of caution and suggestions are presented for the start-ups. Keywords Market assessment · Freedom to operate · Business model · Funding · Commercialization · Capturing value · Go to market · IPR protection strategy · Disclosure of innovation · Unique selling proposition · Target customer segment · Licensing IP · Start-up

6.1 Overview of Product/Technology Development Process The total process starting from the wish to create a solution to the entry of the product in the market is shown in Fig. 6.1. An attempt is made to show all the activities on a timeline (not to scale). It is visible that commercialization activities are diverse and cannot be put in a box. Various activities related to commercialization essentially start quite early in the process. It is worthwhile to invest in market assessment and a short study on freedom to operate (FTO) at the very beginning. FTO will essentially layout a picture of the patents in the area of interest, and this can in turn help in guiding the product development process in terms of the technology development pathway. An early development of the business model canvas (BMC) can help in identifying the potential partners, competitors, and customer segment to be addressed and developing value proposition and revenue chain. This remains as a live document throughout the development process until agreements are signed with potential partners and product launch is secured. Marketing starts quite early in the product development process. It starts by creating awareness among the target customer segments. © The Author(s), under exclusive license to Springer Nature Switzerland AG 2023 B. K. Datta, Fast-Track Innovation and Commercialization: Tools and Techniques, https://doi.org/10.1007/978-3-031-30375-3_6

87

88

6 Key to Successful Fast Track Innovation

Fig. 6.1 Complete process of product development

The key factors for successful fast track innovation can be listed as follows: 1. Identify and understand the need for innovation—When we decide to innovate a new technology, i.e., product/services, we need to understand (a) The problem we are trying to solve so that we respond to the root causes. (b) The need of our customers/end users. If we are solving a problem that’s not relevant to the end users, then it’s unlikely that the innovation will survive the market. (c) The competitive landscape and how the values created in the product can have a competitive edge. 2. A shared vision of the future—Based on the technology development trend, ongoing political discussions on possible regulatory changes, competitor landscape and market opportunities present, we often try to visualize how the market will develop and what sort of product/technology needs to be developed, to meet the market demand/need. There are always some uncertainties and yet the whole company has to get behind the shared vision of the future and then put resources to develop the technology to get to the market at the right time. 3. Well-developed strategy for innovation (technology development) and commercialization—Every new product/service development effort should be coupled with the development/selection of a business model which defines its ‘go to market’ and ‘capturing value’ strategies. Good business model design and implementation, coupled with careful strategic analysis, are necessary for technological innovation to succeed commercially. The strategy must include:

6.2 Commercialization and Its Importance

(a) (b) (c) (d)

89

Assessment of novelty of innovation Assessment of market and marketability of the innovation IPR protection strategy Commercialization strategy.

4. Management involvement and support—The top management must promote a culture for innovation and challenge the employees to innovate. They must show flexibility when it comes to supporting innovative environment, providing needed resources, and help building connection between the innovators and the industry (end user). 5. Creative multidiscipline team—A creative multi-discipline team is an absolute necessity not only for creating an innovation environment, but also for successful innovation. 6. Risk tolerance culture—We must appreciate that any innovation process has to face certain uncertainties and has to solve some questions that have not been solved before. Hence, there is always a chance for failure, from which one must learn and then use that learning to develop further and innovate. 7. A well-defined, yet flexible innovation process—Too many high-potential, breakthrough ideas suffer because they are force-fit into the same pipeline and business model as incremental innovation. These big ideas require nurturing—a flexible process that can help these ideas evolve into something that fills a new space, and at the same time, the process helps eliminate the risks at a very early stage and thus ensures successful development of the innovative product. 8. Relationships—This applies to not only human relationship among the team members, but also between the systems and components. Relationship between the subsystems and components is usually handled by interface engineer. His/her sole focus will be to ensure that there is no conflict between the subsystems/ components at the time on integration. Relationship between the team members is another aspect of vital importance. It is the job of the project manager to ensure easy flow of information between team members and nobody holds back information, which can affect progress/work of another group inside the team. This human aspect is often forgotten in real life. This following section introduces the reader to the basics of commercialization and the process for bringing a product/service to the market and making monetary benefit out of it.

6.2 Commercialization and Its Importance Commercialization is the process of bringing a new product/service to market to meet the market need. Commercialization of products/services has tremendous impact on the country’s economy, and that is why, most governments will encourage and create mechanisms to support commercialization efforts by business entities, universities, and institutions. Successful commercialization of products/service creates often new

90

6 Key to Successful Fast Track Innovation

production facilities, new marketing needs, and logistics to support the products reaching the target customer segment. Naturally, it creates new job opportunities, and this is good for any economy. The process of commercialization of a product/service starts with the ideation of a concept of a product with an intention to bring the product to the market to meet market need and gain monetary benefit out of it. The process involves several steps: ● Disclosure of invention/innovation—Any new concept of product/technology that gives a competitive advantage in the market, needs to be well documented for further follow-up and protected so that one does not lose the competitive advantage. Disclosure of invention is usually documented using DOFI as discussed in Chap. 2. ● Protecting the innovation/invention—IPR (Chap. 2) assessment is carried out at this stage. A brief background check on prior art is run to ensure novelty of the invention. A more thorough investigation of prior art may be done to address potential roadblocks to patent acquisition and enforceability. In some cases, it may be wise to wait for the market to mature before the product is launched. In case if the innovation is difficult to protect using standard tools like patenting, it must be safeguarded closely. ● Define the offer and Unique selling proposition—This should be very clearly stated and should be understandable in unambiguous terms by the target audience. While defining the offer, it is important to highlight unique selling proposition. Once this message with unique selling proposition reaches the customer, it is relatively easy to capture market share. Unique selling proposition of the product must be strong enough to beat the competitors in the market. Unique selling proposition is the value proposition of the product that matches the customer needs/desire as shown in Fig. 6.2. ● Align the product with the company’s core business—This is particularly applicable for companies with established product portfolio. Start-ups normally start building their company with a single new product only. ● Identifying the target customer segment—Without a market need, successful commercialization of an innovation is difficult. Therefore, each invention has to be assessed in order to determine the fit of the technology to the current marketplace. One needs to identify which segment of the market will be targeted to start with, even if initial market assessment shows that there lies a huge market opportunity in different segments. This is important to have laser-focused messaging to the target audience. This is an important information which goes into Business Model Canvas. ● Creating business model—Business model is all about how you are creating value and getting compensated by your customer once they receive your product. This is important in case where the entrepreneur/inventor must convince an entity (higher management/investor/government funding agencies) to finance the project. Investors need to see the viability of commercializing the product, and they must feel comfortable that at the end of the day they will have good return on

6.2 Commercialization and Its Importance

91

Fig. 6.2 Unique selling proposition

● ● ● ● ●

investment. The business model must show plans for all available/possible funds and process involved in bringing the product to the market. Plan for production and logistics—It is important to have a plan in place on how to produce and distribute the product to identified market segment. Sales plan—A suitable sales and marketing plan needs to be in place for the target audience. Time to market—This is an important aspect that needs to be assessed carefully. A product should be launched when it is expected to have a maximum impact on the target customer segment(s). Forecast sales, etc.—Business turnover, return on investment, and business growth for next 3–5 years should be worked out. Business growth plan—It should identify stages when additional funding will be necessary for growth.

All these issues are normally identified at an early stage in the form of business model canvas, which is further refined and fine-tuned as the product development process progresses. BMC can be a dynamic document, and the strategy and strategic partners can change as the product gets developed and the needs get more clarified.

92

6 Key to Successful Fast Track Innovation

6.2.1 Commercialization Pathways There are usually four pathways to get any innovation to the market and each demands different level of company structure and marketing needs. The pathways for commercialization are: 1. 2. 3. 4.

Licensing the IP to a third party In-house production and sales using own infrastructure In-house production but sale through partner companies Off-load production to a partner company and sale through partner companies/channels. This again is guided by which business model is chosen.

Licensing the IP to a third party—In this case, the owner company of the IP enters into an agreement with a suitable entity who agrees to gain the rights to utilize the IP for a given amount of money and/or royalty or an agreeable combination of both money and royalty for a given number of years. During such discussion process, it is usual that both the parties sign a mutual NDA, before they disclose any trade secrets to each other. In this case, the owner of the invention gains income without any further investment in production, marketing, and sales. In-house production and sales—This option is usually more suitable for a company, which has already established competence in manufacturing and has infrastructure and resources for sales and marketing. The company can keep all the profits, but this comes with also the probability of failure/loss. This needs investments as well. A well-thought-out business plan must be prepared and followed up closely during implementation. Return on investment must be closely followed up, and any deviation has to be addressed. Collaborating with partner companies—One can choose to get the product manufactured at a partner company and sale through another partner company. In both of these cases, the total profit gets reduced, but the company retains the IPR.

6.3 A Few Words for Start-Ups A start-up is a very common term these days. People often make mistake between a start-up and a small business. A start-up is a “temporary organization designed to search for a repeatable and scalable business model” as defined by Silicon Valley legend Steve Blank [1]. While a start-up essentially has an intent to become a large business, a small business usually does not have such intent. Therefore, the driving force behind the business models of a start-up and a small business is quite different. A small business usually tries to create a place for the business in the local marketplace. Another difference is the life span of the business. While a small business may live

6.3 A Few Words for Start-Ups

93

for a number of years, a start-up usually has an exit plan and develops into a large business, often international. High-tech start-ups are coming up all over the world both in developed world as well as in emerging economies. Usually, high-tech start-ups also have a high failure rate. Interestingly, high-tech start-ups thrive in the presence of an entrepreneurial ecosystem. A high-tech start-up creation and management leading to success is not an easy task! It involves tackling a wide range of tasks and challenges. Once a person has got an excellent idea, he/she is tempted to create a company, develop the idea further into a product, and enter the market and start selling the product. Planning is perhaps the most important and crucial task and yet often not given its due weightage by the start-ups. As soon as a decision is made to create a start-up for developing the idea into a product, it is of extreme importance to: ● Understand the industry sector/s where the product will be relevant. ● Get familiar with the policy initiatives applicable to the proposed product domain and use them to create value. ● Understand and learn about the competitors in the market. ● Understand the risks involved. ● Map out the financing plan/strategy. ● Identify potential end user that could play an active role during the technology development phase and also trial. ● Understand the strength and weakness of the entrepreneurial ecosystem where the start-up will be operating. ● Create a marketing plan. ● Prepare business projections and necessary documentation for pitching idea to potential investors. In short, it is the time to start with the business model using Business Model canvas. This will give a visual presentation of the challenges to be tackled. Getting organized is also very important. Being a lone start-up entrepreneur can be very demanding and lonely. A good technologist is in all probability not a good manager or a good businessman. Naturally, one should try to get access to trustworthy and seasoned advisors by associating with an entrepreneurial ecosystem. Business ideas, strategies, challenges, and progress should be discussed with wise counsel to avoid any pitfalls. Organizing business structure and tax consequences is another topic which must be given due consideration. At the time of incorporation of a start-up, the entrepreneur should think of long-term plan. It is the time to decide whether the shares will be held personally or through a holding company. When the start-up company grows and attracts buyers, consequence of capital gains on shares must be considered. Usually, input value of shares of such start-ups is very low. If it grows in value considerably, sale of the shares will attract a high capital gains tax. This can be easily avoided by holding the shares through a holding company. This creates a more flexible solution for both the entrepreneur and the start-up company.

94

6 Key to Successful Fast Track Innovation

Revenue generating plan is another important aspect at this stage. After identifying the potential market segments and customer groups, it is important to make plan for how to start generating revenue and then slowly and strategically grow. It will be totally unrealistic to try to set foot on every possible market segment simultaneously. Being overconfident can be disastrous for the start-up. While a start-up entrepreneur must have confidence in his/her product, otherwise nobody else will believe in their product either and it will not be possible to get the investors on board! However, agile approach is very important. Open mind to accept any constructive suggestion can go a long way in helping become successful. One should not be too stubborn to stick to the original ideas. Often the final product may look totally different at the commercialization stage, from the original idea. Understanding the importance of funding is very important for success or failure of start-up. A lot of start-ups assume that they will be super-efficient, and everything will happen without any glitch or failure. But one should not forget the Murphy’s law— “Anything that can go wrong will go wrong.” Things do go wrong and don’t always happen the way we want them to happen. As a result, time flies by and resources get eaten up faster than it was planned. Asking for less money than realistic can give investors less confidence in the project. Further, asking for second round of money that was not envisaged earlier or was not presented in the earlier plan can make investors uneasy and feel less confident about investing further. A good understanding of the avenues for securing funding can be very important for the start-ups. Every country is trying to encourage start-ups and thereby job creation. Seed funding is the earliest capital raised by a start-up. Seed funding comes often from founders themselves, friends and relatives, and crowdfunding and also from angel investors. A start-up should approach a seed investor, only when one has a strong case of product, market, and team to develop into a company. The start-up should be able to convince the investor that the team can help the start-up to grow and thereby lead to generation of return on investment. Scaling up too fast is one mistake many start-ups make. A start-up must not only ensure that their product can actually solve the needs of the growing user segments but also they have business system, infrastructure, and resources available to support the growing demand without creating any bad customer experience in the process.

Reference 1. Switters JM, Tageo V, Pujol L (2017) Final evaluation report; learning incrementally from failed enterpreneurship: H2020—GA645000. [Internett]. https://ec.europa.eu/research/participa nts/documents/downloadPublic?documentIds=080166e5afc387fd&appId=PPGMS. Ref. Ares 376620—24 Jan 2017

Appendix A

Disclosure of Invention

INVENTORS INVENTOR 1

INVENTOR 2

Name Position Department Email Date Inventorship %

Name Position Department Email Date Inventorship %

TITLE - Project name - One-line description

THE PROBLEM

max. 200 words

- What problem does your idea solve? - Who has this problem? - How is the problem solved today?

THE SOLUTION

max. 200 words

- What is your proposed solution and how will it be used?

STATE OF THE ART

max. 200 words

- What are the main competing solutions today in the market or under development? - What is the main advantage(s) of your solution over the best current solution?

© The Editor(s) (if applicable) and The Author(s), under exclusive license to Springer Nature Switzerland AG 2023 B. K. Datta, Fast-track Innovation and Commercialization: Tools and Techniques, https://doi.org/10.1007/978-3-031-30375-3

95

96

Appendix A: Disclosure of Invention

DEVELOPMENT STAGE Please mark the TRL level that best describes the current status of the technology development. TRL 1: Basic principles observed TRL 2: Technology concept formulated TRL 3: Experimental proof of concept TRL 4: Technology validated in lab – Lab scale prototype built TRL 5: Prototype tested in relevant environment (e.g. industrially relevant environment) TRL 6: Prototype tested in intended environment & close to expected performance TRL 7: System prototype demonstration in operational environment TRL 8: System complete and qualified – manufacturing issues resolved TRL 9: Technology available for market Further comments regarding the technology development, e.g., identified challenges, tests carried out, most important activities needed to increase TRL, and required resources to do so

COMMERCIAL POTENTIAL

max. 200 words

- What, in your opinion, is the commercial potential of the idea? Give a brief assessment based on the knowledge you have of the market and any potential applications of the idea.

RESEARCH, PUBLISHING & PATENTING Is this idea a result of a current or previous research project?

Has the idea been published? Patenting presupposes that the idea has not previously been published.

Do you have publication?

plans

for

No Yes If yes, please provide further details.

No Yes If yes, please provide further details.

No Yes If yes, please provide further details.

TEAM If this project were funded to further develop the technology, please indicate who would be the Project Lead and support roles to carry out such development

Appendix B

Mutual Non-disclosure Agreement

THIS MUTUAL NON-DISCLOSURE AGREEMENT (the “Agreement”) is entered into between XXX, with its principal place of business at xxxxx, and YYY, at (address) (collectively, the “Parties”) as of xxth of month year (the “Effective Date”). In order for the Parties to discuss a business relationship, the Parties may find it necessary or desirable to disclose to each other certain business and other information that each considers to be confidential or proprietary. In order to protect the confidentiality of such information, and in consideration of the exchange of such information, the Parties agree as follows: 1.

2.

Definition of Confidential Information. “Confidential Information” means any and all information, however transmitted, that is or has been received by either party (the “Recipient”) from the other party (the “Disclosing Party”) and that (a) is marked as “confidential”, “proprietary”, or “secret”, or (b) is information which relates to the Disclosing Party’s business which the Disclosing Party treats as confidential. Without limiting the generality of the foregoing, Confidential Information shall include trade secrets and other confidential and/or proprietary information, business plans, informational memorandums, reports, investigations, research, work in progress, source codes, object codes, technical manuals, marketing and sales programs, financial statements, projections and other financial information, cost summaries, pricing formulae, contract analyses, confidential filings with any domestic or foreign government agency, customer lists and identities and all other confidential concepts, methods of doing business, ideas, materials or information prepared or performed by on behalf of the Disclosing Party by its employees, officers, directors, agents, representatives, or consultants, as well as the pricing and payment provisions of any subsequent written agreement(s) between the Parties and any discussions or negotiations leading up to such agreement(s). Excluded Information. Confidential Information shall not include any information that: (a) Prior to disclosure by the Disclosing Party is already lawfully and rightfully known by or available to the Recipient as evidenced by prior

© The Editor(s) (if applicable) and The Author(s), under exclusive license to Springer Nature Switzerland AG 2023 B. K. Datta, Fast-track Innovation and Commercialization: Tools and Techniques, https://doi.org/10.1007/978-3-031-30375-3

97

98

3.

4.

5.

Appendix B: Mutual Non-disclosure Agreement

written records or other documents in possession of the Recipient; (b) Through no wrongful act, fault or negligence on the part of the Recipient is or hereafter becomes part of the public domain; (c) Is lawfully received by the Recipient from a third party without restriction and without breach of this Agreement or any other agreement; (d) Is approved for public release for use by written authorization for the Disclosing Party; (e) The Recipient can demonstrate was independently developed by it without reference to the Disclosing Party’s Confidential Information; or (f) Is disclosed pursuant to the requirement or request of a governmental agency or court of competent jurisdiction and sufficient notice is given by the Recipient to the Disclosing Party of any such requirement or request in order to permit the Disclosing Party to seek a protective order or exemption from such requirement or request. Protection of Confidential Information. Each party shall take all reasonable security precautions to protect the Confidential Information, at least as strict as the precautions it takes to protect its own confidential and proprietary information or similar nature. The Recipient of Confidential Information shall restrict the disclosure, dissemination, and availability or Confidential Information to its directors, employees, advisors, and independent contractors (collectively “Permitted Personnel”) with a demonstrable need to know such Confidential Information. Each party shall execute appropriate written agreements with its Permitted Personnel sufficient to ensure that it complies with the provisions of this Agreement. Neither party shall (a) use any Confidential Information received by it or any work product derived from such Confidential Information in any way other than in pursuance of the Parties’ mutual relationship, (b) disclose or make available to any third party (other than the Permitted Personnel) any Confidential Information received by it or any work derived from such Confidential Information, without prior written consent of the Disclosing Party; (c) use any Confidential Information received by it to develop a product or service which competes with or imitates products of the Disclosing Party; (d) make any attempt to reverse engineer, disassemble or decompile any prototypes, software or other objects which embody the other party’s Confidential Information; or (e) otherwise use the other’s Confidential Information or any work product derived from such Confidential Information for its own benefit or the benefit or a third-party without written authorization from the Disclosing Party, including without limitation, reverse engineering of any products through use of Confidential Information. Related Parties. This agreement is entered into by each party on its own behalf and on behalf of all its directors, officers, employees, advisors, independent contractors, affiliates, subsidiaries, and related companies (collectively, “Related Parties”), and shall be binding upon them. Each party shall be responsible for ensuring that its Related Parties comply with the terms of this Agreement, and shall be liable for any breach of this Agreement by its Related Parties. Rights to Confidential Information. All Confidential Information and all rights in the Confidential Information received by a Recipient shall remain the

Appendix B: Mutual Non-disclosure Agreement

99

sole and exclusive property of the Disclosing Party. Upon written request by the Disclosing Party, the Recipient shall return to the Disclosing Party, or shall destroy in a manner satisfactory to the Disclosing Party, all forms of Confidential Information, including any and all copies of the Confidential Information or notes containing the Confidential Information, and shall provide a written certification to the Disclosing Party that all forms of the Confidential Information have been returned or destroyed. 6. Liabilities. Except as may otherwise be explicitly provided in any subsequent agreement between the parties, the confidential information is provided “As is” and the disclosing party hereby excludes all representations, warranties, and conditions, express or implied, including any representations, warranties or conditions of accuracy, sufficiency, suitability or non-infringement. The disclosing party shall have no liability whatsoever for any damages, losses or expenses incurred by the recipient as a result of its receipt or use of information pursuant to this agreement, whether arising in contract, tort or otherwise. The parties acknowledge that the limitations described in this article and the allocation of risks and benefits under this agreement are a fundamental part of this agreement. 7. No Obligations, License, Etc. Nothing contained in this Agreement shall be construed as (a) requiring either party to disclose or accept information, (b) requiring either party to purchase or use any products, goods, or facilities of or to the other party, or (c) granting to the Recipient of Confidential Information any rights by license or otherwise, either express or implied, under any patent, copyright, trade secret or other intellectual property right now or hereafter owned, obtained or licensable by the Disclosing Party. This Agreement does not represent nor imply an agreement or commitment to enter into any further business relationship. This Agreement does not create any agency or partnership between the Parties or authorize a Party to use the other Party’s name or trademarks or other intellectual property. 8. Remedies for Breach. The Parties agree that money damages would be inadequate to remedy any breach of this Agreement. As a result, a non-breaching party shall be entitled to seek, and a competent jurisdiction may grant, specific performance and injunctive or other equitable relief as a remedy for any breach of this agreement. Such remedy shall be in addition to all other remedies, including money damages, available to a non-breaching party at law or in equity. 9. Notices. Any notice given by one Party to the other under this Agreement shall be sent by registered mail, return receipt requested, or reputable overnight courier to the address listed above (or such address changed by the giving of written notice to the other Party), and shall be deemed received upon actual receipt by the recipient Party. 10. Successors and Assigns. The terms and conditions of this Agreement shall inure to the benefit of and be binding upon the respective successors an assign of the Parties, provided that Confidential Information of the Disclosing Party may not be assigned by the Recipient without the prior written consent of the Disclosing Party unless assignee shall be the successor entity to the assignor upon the

100

11.

12. 13.

14.

15.

16.

Appendix B: Mutual Non-disclosure Agreement

dissolution of the assignor in its present form. Nothing in this agreement, express or implied, is intended to confer upon any party other than the Parties hereto or their respective successors and assigns any rights, remedies, obligations, or liabilities under or by reason of this Agreement, except as expressly provided in this Agreement. Entire Agreement. This Agreement sets forth the entire agreement between the Parties hereto with respect to its subject matter, and any and all prior agreements, understandings or representations with respect to its subject matter are merged herein. In the event of a conflict between the terms of this Agreement and any subsequent written agreement between the Parties, the scope of the rights and obligations contained in this Agreement shall be deemed modified in such manner as to be consistent with such agreement, but to maximize as much as possible the protection afforded to the Confidential Information under this Agreement. Amendments. This Agreement may be amended only by written agreement of the Parties. Governing Law. This Agreement, including all matters of construction, validity and performance, shall be governed by, construed and enforced in accordance with the laws of Norway, as applied to contracts made and to be fully performed in such state without regard to its conflict of law rules. Severability. If any provision of this Agreement is held by a court of competent jurisdiction to be invalid, illegal, or unenforceable, the validity, legality and enforceability of the remaining provisions shall not in any way be affected, impaired or invalidated thereby. Counterparts. This Agreement may be executed in two or more counterparts, each of which shall be deemed an original, and all of which together shall constitute one and the same instrument. Headings. The headings in this Agreement are intended for convenience of reference and shall not affect in any way the meaning or interpretation of this Agreement.

IN WITNESS WHEREOF, the Parties have executed this Agreement as of the Effective Date written above. XXX

YYY

By: _____________________________

By: _____________________________

Name:

Name:

Title:

Title:

Appendix C

Business Model Canvas

Team or Company Name:

Date:

Top of Form

Primary Canvas Alternative Canvas

The Business Model Canvas Key Partners etc.

Key Activities etc.

Key Resources

Cost Structure

Value Proposition

Customer Relationships

Customer Segments

Channels

Revenue Streams

© The Editor(s) (if applicable) and The Author(s), under exclusive license to Springer Nature Switzerland AG 2023 B. K. Datta, Fast-track Innovation and Commercialization: Tools and Techniques, https://doi.org/10.1007/978-3-031-30375-3

101

Appendix D

System Requirements Document

Doc. no.:xxxxxxxx Issue:

System requirements document xx

Name/ Dept:

xxxxxxx

Tel.:

Responsible: Tel.:

xxxxxx

Date: xx.xx.xxxx

Page: 1 of 25

Project & task:

Attachments:

Proj.

None

Customer:

Distribution

System requirements - xxxxxx xxx system

Summary This specification lists system requirements for xxxx xxx system that is being designed to actively control the xxxxx. The system consists of xxxxxxx. The system requirements will in later project phases be further detailed in HW and SW component design specifications.

Issue

Date

Prepared

Approved

Changes from last Revision

A B

© The Editor(s) (if applicable) and The Author(s), under exclusive license to Springer Nature Switzerland AG 2023 B. K. Datta, Fast-track Innovation and Commercialization: Tools and Techniques, https://doi.org/10.1007/978-3-031-30375-3

103

104

Appendix D: System Requirements Document

Table of Contents Summary ...................................................................................................................................................................103 Table of Contents ......................................................................................................................................................104 1 SCOPE...............................................................................................................................................................105 1.1 Identification ................................................................................................................................................105 1.2 Document Overview ....................................................................................................................................105 1.3 Definitions and abbreviations ......................................................................................................................105 2 References .........................................................................................................................................................108 2.1 Document history ........................................................................................................................................108 3 System Description ............................................................................................................................................109 3.1 Business......................................................................................................................................................109 Here comes an introduction of the business eco-system and the challenges for which a solution is needed......109 3.2 Initial need ...................................................................................................................................................109 3.3 Stakeholder requirements ...........................................................................................................................109 3.4 Context ........................................................................................................................................................109 3.5 Interfaces ....................................................................................................................................................110 3.6 Stakeholders ...............................................................................................................................................110 3.7 Use cases ...................................................................................................................................................110 3.8 Operational modes ......................................................................................................................................110 3.9 States ..........................................................................................................................................................110 3.10 Load scenarios ........................................................................................................................................111 3.10.1 External impact ....................................................................................................................................111 3.10.2 Operational ..........................................................................................................................................111 4 Requirements specification ................................................................................................................................111 4.1 Functional....................................................................................................................................................111 4.1.1 SW version retrievable.........................................................................................................................112 4.1.2 System status monitoring ....................................................................................................................112 4.1.3 Configuration of system parameters ....................................................................................................112 4.1.4 SW upgrade .........................................................................................................................................113 4.1.5 Hot-swap ..............................................................................................................................................113 4.1.6 Hot swap xxx computer .......................................................................................................................113 4.1.7 Log key system events ........................................................................................................................114 4.2 Non functional .............................................................................................................................................114 4.2.1 Performance / capability ......................................................................................................................114 Battery capacity (UPS) .................................................................................................................114 4.2.2 Safety, health, environmental protection .............................................................................................114 Operator safety - sharp edges ......................................................................................................115 Operator safety - squeezing .........................................................................................................115 Battery removal ............................................................................................................................115 4.2.3 Quality ..................................................................................................................................................115 Single point of failure ....................................................................................................................115 Redundant power supply ..........................................................................................................116 Redundant communication lines ...............................................................................................116 Maintenance - Online ...................................................................................................................116 Ease of access .............................................................................................................................116 4.2.4 Law, regulation, standard ....................................................................................................................117 4.2.5 Metrics (dimension, weight etc) ...........................................................................................................117 Weight...........................................................................................................................................117 Build space for equipment - instrument room...............................................................................117 4.2.6 External interface .................................................................................................................................117 Lifting points ..............................................................................................................................118 Power supply from xxx .................................................................................................................118 4.2.7 Environmental properties .....................................................................................................................118 Electro Magnetic Compatibility (EMC)..........................................................................................118 Electrical noise .............................................................................................................................118 Temperature range - operation ....................................................................................................119 Temperature range - storage .......................................................................................................119 Enclosure protection - IP code .....................................................................................................119 4.2.8 Materials ..............................................................................................................................................120

Appendix D: System Requirements Document

5 6

105

Material corrosion .......................................................................................................................120 Tools ...........................................................................................................................................120 Material degradation ...................................................................................................................120 Hazardous materials...................................................................................................................121 RoHS - Restriction of Hazardous Substances Directive ............................................................121 4.2.9 Design and construction ....................................................................................................................121 Tagging of unit ............................................................................................................................121 SW components - compatibility ..................................................................................................122 Protection against entanglement ................................................................................................122 Use COTS components..............................................................................................................122 Ease of assembly/disassembly ..................................................................................................122 Replaceable units .......................................................................................................................123 Fail-safe priority ..........................................................................................................................123 4.2.10 Human factors ...................................................................................................................................123 Outdoor user interface - readability ............................................................................................123 Verification........................................................................................................................................................124 Traceability ....................................................................................................................................................... 124 References .......................................................................................................................................................128

D.1 Scope D.1.1 Identification This document specifies the system requirements for the xxx system. Guidance: This paragraph contains a full identification of the system or subsystem and associated software to which this document applies, including as applicable, identification number(s), title(s), abbreviation(s), and release number(s) where known.

D.1.2 Document Overview Section 1—Introduction to document, definitions, abbreviations and references. Section 2—System description. Section 3—System requirements. Section 4—Verification. Section 5—Traceability. Section 6—List of requirements.

D.1.3 Definitions and Abbreviations Systems Engineering Terminology

106

Appendix D: System Requirements Document

Name

Description

Baseline

Baseline Specification of work product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures. Ref ISO15288:2008

Feature

A feature is part of the solution domain: a service that the system provides to fulfil one or more stakeholder needs. Provides a top level solution to the problem—does not design a solution, but what a viable design should accomplish

Functional

Requirements describing system functionality, services of the system

Need

A need is part of the problem domain: the business or operational problem (opportunity) that is requested solved to justify purchase or use of the system—the Stakeholder(s) expectation from the system—the goal/intention for the system—realized by system Features

Non-functional

Requirements describing system attributes, constraints and qualities. The non-functional requirements restricts/influences the functionality of the system by defining conditions for the Functional requirements

Operator

Entity that performs the operation of a system. Ref ISO15288:2008

Qualification

Process of demonstrating whether an entity is capable of fulfilling specified requirements. Ref ISO15288:2008

Requirement status

The following categories are used to define the state of the requirement: • Pending: Requirement in work • To be reviewed: Requirement is ready for (internal) review • Review passed: Requirement passed (internal) review • Accepted: Requirement formally accepted by stakeholders/customer • Rejected: Requirement rejected (internal review or customer acceptance) • Change request: Formal request to change requirement after it has reached Accepted status. A signed change request shall be linked to the requirement. If and when a change request is accepted, the requirement is set to status Pending until changes have been implemented as proposed • Cancelled: Requirement has been cancelled • None assigned: This is no requirement

Requirement

A singular documented need of what a particular product or service should be or do. A statement that identifies a necessary attribute, capability, characteristic or quality of a system in order for it to have value or utility to a stakeholder

Shall

Syntax used to signal a mandatory requirement. Deviation must be formally accepted internally and externally

Should

Syntax used to signal a non-mandatory requirement. Deviation must be formally accepted internally and externally (continued)

Appendix D: System Requirements Document

107

(continued) Name

Description

Stakeholder

Individual or organization having a right, share, claim, or interest in a system or in its posession of characteristics that meet their needs and expectations (Ref ISO15288:2008) The stakeholders have a legal interest or a stake in the outcome of the engineering of the system Users: The person, groups, companies who will interact with the system and control it directly, and those who will use the results of it Developers: Those responsible for design, development, introduction and maintenance Legislators: Those who produce laws, guidelines and standards that affect the development or operation of the system Decision-makers: Those who have any power over the decision to build the system, or over any processes, people or standards identified earlier

System

Combination of interacting elements organized to achieve one or more stated purposes. A system may be considered as a product or as the service it provides (Ref ISO15288:2008): – Systems have structure, defined by parts and their composition – Systems have behaviour, which involves inputs, processing and outputs of material, energy or information – Systems have interconnectivity: The various parts of a system have functional as well as structural relationships between each other – System(s) have by itself function(s) or group of functions

Systems Engineering An interdisciplinary process that ensures that the customer’s needs are satisfied throughout a system’s entire life cycle In simple terms, the approach consists of identification and quantification of system goals, creation of alternative system design concepts, performance of design trades, selection and implementation of the best design, verification that the design is properly built and integrated, and post-implementation assessment of how well the system meets (or met) the goals Validation

Confirmation, through the provision of objective evidence, that the requirements for a specific intended use or application have been fulfilled Validation is the set of activities ensuring and gaining confidence that a system is able to accomplish its intended use, goals and objectives (i.e., meet the stakeholder requirements) in the intended operational environment Ref ISO15288:2008

Verification

Confirmation, through the provision of objective evidence, that specified requirements have been fulfilled Verification is a set of activities that compares a system or system element against the required characteristics Ref ISO15288:2008

Abbreviations and Acronyms

108

Appendix D: System Requirements Document

D.2 References Reference list Doc no

Ref doc nr.

Name

Additional information

Praject no.

Baseline

Baseline date

Database reference Database name

D.2.1 Document History Changes from revision A to revision B. Guidance: all the changes are noted here. Page or requirement (in A revision)

Change

13

Updated reference to XX and added new reference to xxx

13

xx TBD fixed

28

Removed TBD and changed text describing restrictions of xxx angle near vessel

622-Req0043 Configuration of system parameters

‘TBD during detailed design’ removed Changed description of input parameter separation XXX Battery low charge level removed as input parameter

Notes

No need to update this document with details—will be described in operation manual During production, each source will be controlled by a pre plot reference; hence the separation distance is implicit. Default separation parameter can be used for preparing positioning prior to production Suggested design implements a simplified charging control—charge level monitored by binary low/high signal

Appendix D: System Requirements Document

109

D.3 System Description D.3.1 Business Here comes an introduction of the business eco-system and the challenges for which a solution is needed.

D.3.2 Initial Need The need for development is described here.

D.3.3 Stakeholder Requirements A set of stakeholder requirements have been specified in the xxxxxxxx. • Stakeholders are identified with their role and main points of interest. • Needs are defined, describing the stakeholder(s) expectation of the system. • Features are defined, stating the top level requirements to the system. The Features represent solutions to solve the Stakeholder Needs. The system requirements in this specification are derived from the Stakeholder requirements and further detailed during system design activities. While the Stakeholder requirements represent top level requirements used in system concepts evaluation, the System requirements represent requirements to the system design and will act as input to detailed design requirements for hardware and software components during the detailed design phase.

D.3.4 Context Guidance: Here comes the Context diagram/s of all the control system. A Context Diagram defines the boundary between the system or part of a system and the surrounding environment and shows the entities that interact with it at a high level view of the system and can be shown as block diagrams.

110 Table D.1 System stakeholders and their main area of interest

Appendix D: System Requirements Document Name

Description

xxxxx

Representing xxxx Main areas of interest: – Derived interests: –

xxxxxxx

Representing xxxx Main areas of interest: – Derived interests: –

D.3.5 Interfaces Guidance: Here comes a pictorial representation of the interfaces between systems and block diagram is often used.

D.3.6 Stakeholders (Table D.1)

D.3.7 Use Cases Guidance: Here comes the use cases for the operation of the control system, service of the system and manufacture of the components.

D.3.8 Operational Modes Guidance: Here comes the description of all operation modes.

D.3.9 States Guidance: Here comes the description of all the control states.

Appendix D: System Requirements Document

111

Table D.2 External impact load scenarios Scenarios

Parameters

Loads

Comments

D.3.10 Load Scenarios D.3.10.1

External Impact

Table D.2 lists dimensioning external impact scenarios that the xxx system must be designed to handle, unless it by design is shielded against the scenario.

D.3.10.2

Operational

Table D.3 lists dimensioning operational scenarios that the system must be designed to handle. These result in static and dynamic load requirements.

D.4 Requirements Specification Guidance: Here comes the description of all the control states.

D.4.1 Functional Guidance: Here comes a list of functional requirements, their priority, test status and required status at the end of the project. Table D.3 Applicable operational load scenarios Scenarios

Parameters

Loads

Comments

112

Appendix D: System Requirements Document

--------------------------------------------------------------------------------Req00xx

D.4.1.1

SW Version Retrievable

It shall for each xxxx application, without any special tools, be possible to retrieve information about the version of the SW installed. Req priority: Medium Test status: Not performed Req status: Reviewed --------------------------------------------------------------------------------Req00xx

D.4.1.2

System Status Monitoring

The xxx shall during operation monitor health status with respect to communication, power supply, and xxx operability. Comment: Req priority: Medium Test status: Not performed Req status: Reviewed --------------------------------------------------------------------------------Req00xx

D.4.1.3

Configuration of System Parameters

The xxx shall provide a method of modifying as a minimum the following configuration parameters prior to system start-up: Comment: Req priority: Medium Test status: Not performed Req status: Reviewed --------------------------------------------------------------------------------Req00xx

Appendix D: System Requirements Document

D.4.1.4

113

SW Upgrade

The xxxx shall implement a method of upgrading applied SW components with new versions. Req priority: Medium Test status: Not performed Req status: Reviewed --------------------------------------------------------------------------------Req00xx

D.4.1.5

Hot-Swap

The xxx shall permit exchange of one xx with a new one. Comment: Hot swap requires a spare xx, it does not mean switching xxx locations internally. Req priority: Medium Test status: Not performed Req status: Reviewed --------------------------------------------------------------------------------Req00xx

D.4.1.6

Hot Swap XXX Computer

The xx shall permit replacement of the xxcomputer during Production while maintaining a fixed settings for each controlled xxx and resuming full functionality after successful replacement. Comment: Operational procedure (manual action) may be required to ensure that a backup of current configuration parameters exists at all times and can be used by the replacement computer. Req priority: Medium Test status: Not performed Req status: Reviewed --------------------------------------------------------------------------------Req00xx

114

D.4.1.7

Appendix D: System Requirements Document

Log Key System Events

It should implement a mean and method of storing key system events: • Collision warnings • System failure events • External system (interfacing) failure events Comment: Operational parameters and system configuration will be logged during test and development period for debugging and analysis purpose. Req priority: High Test status: Not performed Req status: Reviewed

D.4.2 Non Functional Guidance: Here comes a list of non-functional requirements, their priority, test status and required status at the end of the project.

D.4.2.1

Performance/Capability

--------------------------------------------------------------------------------Req00xx

Battery Capacity (UPS) The system shall include an UPS unit with the capacity to perform at least 10 complete operations of the system from one end-position to the other when in sea at 0 [°C] temperature, and where each operation is completed within 10 [s]. Comment: Agreed with customer as sufficient for prototype. Subject to change based on experience from prototype testing. Req priority: Medium Test status: Not performed Req status: Reviewed D.4.2.2

Safety, Health, Environmental Protection

--------------------------------------------------------------------------------Req00xx

Appendix D: System Requirements Document

115

Operator Safety—Sharp Edges The system should be designed to have no sharp edges or corners that could hurt the operator during handling; sharp edges and corners which can present a personal safety hazard shall be rounded to a radius of minimum 1 [mm]. Req priority: Low Test status: Not performed Req status: Reviewed --------------------------------------------------------------------------------Req00xx

Operator Safety—Squeezing The system shall be designed to ensure a minimum risk of injuring personnel by squeezing body parts during handling and maintenance. Req priority: Medium Test status: Not performed Req status: Reviewed --------------------------------------------------------------------------------Req00xx

Battery Removal The system shall be designed to enable removal of batteries for the purpose of storage in a dedicated safe storage area. Req priority: Medium Test status: Not performed Req status: Reviewed D.4.2.3

Quality

--------------------------------------------------------------------------------Req00xx

Single Point of Failure The system design should ensure that no single point of failure results in loss of control or operational downtime.

116

Appendix D: System Requirements Document

Req priority: Medium Test status: Not performed Req status: Reviewed --------------------------------------------------------------------------------Req00xx Redundant Power Supply The system shall implement a redundancy in power supply. Req priority: Medium Test status: Not performed Req status: Reviewed --------------------------------------------------------------------------------Req00xx Redundant Communication Lines The system shall implement a redundant communication path. Req priority: Medium Test status: Not performed Req status: Reviewed --------------------------------------------------------------------------------Req00xx

Maintenance—Online The system shall not require regular Online maintenance. Req priority: Medium Test status: Not performed Req status: Reviewed --------------------------------------------------------------------------------Req00xx

Ease of Access The system shall provide access for inspection, maintenance and replacement of defined replaceable units.

Appendix D: System Requirements Document

117

Req priority: Medium Test status: Not performed Req status: Reviewed D.4.2.4

Law, Regulation, Standard

D.4.2.5

Metrics (Dimension, Weight Etc.)

--------------------------------------------------------------------------------Req00xx

Weight The GSC hardware shall in total not exceed a weight of 500 [kg]. Fugro, TBC: Input needed on permitted weight on front and aft Gun-string lift-point (trolley lift capacity). See also 622-Req0228 Gun-string centre of gravity. Req priority: Medium Test status: Not performed Req status: Reviewed --------------------------------------------------------------------------------Req00xx

Build Space for Equipment—Instrument Room The xxx equipment to be located in the instrument room should fit in a 19'' rack with internal depth and height at 80 [cm] and 120 [cm] to accommodate xxx system and xxx power modules. Req priority: Medium Test status: Not performed Req status: Reviewed Req status:

D.4.2.6

External Interface

--------------------------------------------------------------------------------Req00xx

118

Appendix D: System Requirements Document

Lifting Points The system shall not interfere with the existing lifting points. Req priority: Medium Test status: Not performed Req status: Reviewed --------------------------------------------------------------------------------Req00xx

Power Supply from xxx The system shall be supplied with TBD × 230 [V], 50 or 60 [Hz], 16 [A] power from the xxx. Comment: Number of circuits to be decided after trials. Req priority: Medium Test status: Not performed Req status: Reviewed D.4.2.7

Environmental Properties

--------------------------------------------------------------------------------Req00xx

Electro Magnetic Compatibility (EMC) The system shall be designed to shield against electromagnetic interference in accordance with standard practice for EMC design. Req priority: Medium Test status: Not performed Req status: Reviewed --------------------------------------------------------------------------------Req00xx

Electrical Noise The system shall not generate any electrical noise that may impair the functionality of interfacing external systems.

Appendix D: System Requirements Document

119

Req priority: Medium Test status: Not performed Req status: Reviewed --------------------------------------------------------------------------------Req00xx

Temperature Range—Operation All weather exposed hardware shall be designed to operate continuously in a temperature range from −10 to + 55 [ºC]. Req priority: Medium Test status: Not performed Req status: Reviewed --------------------------------------------------------------------------------Req00xx

Temperature Range—Storage All weather exposed hardware shall be designed for storage in a temperature range from −35 to + 60 [ºC]. Note! Battery may require removal and maintenance charging during long time storage. Req priority: Medium Test status: Not performed Req status: Reviewed --------------------------------------------------------------------------------Req00xx

Enclosure Protection—IP Code The system shall be designed to protect electrical hardware with an enclosure protection rated to IP68 of IEC 60,529 (Ref. [1]), meaning dust tight enclosure suitable for immersion up to 10 [m] in water. Req priority: Medium Test status: Not performed Req status: Reviewed

120

D.4.2.8

Appendix D: System Requirements Document

Materials

--------------------------------------------------------------------------------Req00xx

Material Corrosion The equipment shall be constructed of materials that will resist the corrosive environment of sea water and galvanic corrosion within its defined lifetime, with guidance from NORSOK standard M-001, Materials selection, and NORSOK standard M-503, Cathodic protection. Req priority: High Test status: Not performed Req status: Reviewed --------------------------------------------------------------------------------Req00xx

Tools The system should only require metric and commercially available tools during installation, maintenance, inspection, operation and other regular activities. Req priority: Low Test status: Not performed Req status: Reviewed --------------------------------------------------------------------------------Req00xx

Material Degradation The equipment materials shall not significantly change properties during their specified life when subjected to environmental effects from operation. Req priority: Medium Test status: Not performed Req status: Reviewed --------------------------------------------------------------------------------Req00xx

Appendix D: System Requirements Document

121

Hazardous Materials The system shall ensure that the use of hazardous materials and substances is minimised, and if such are necessary, these shall be approved by xxx, clearly marked and listed along with argumentation for selection and Material Safety Data Sheets (documented). Req priority: Medium Test status: Not performed Req status: Reviewed --------------------------------------------------------------------------------Req00xx

RoHS—Restriction of Hazardous Substances Directive The system shall use the RoHS directive 2002/95/EC for electronic components. Req priority: Medium Test status: Not performed Req status: Reviewed D.4.2.9

Design and Construction

--------------------------------------------------------------------------------Req00xx

Tagging of Unit The system shall tag all replaceable units with minimum: • • • •

Manufacturer Serial number Part number Version

Comment: TBD by xxxx. Req priority: Medium Test status: Not performed Req status: Reviewed --------------------------------------------------------------------------------Req00xx

122

Appendix D: System Requirements Document

SW Components—Compatibility The system shall implement a method that ensures that all custom made SW modules installed are internally compatible, including when they are installed on physically separate HW-components. Req priority: High Test status: Not performed Req status: Reviewed --------------------------------------------------------------------------------Req00xx

Protection Against Entanglement The hardware shall be designed to minimize the risk of entanglement with ropes, umbilicals or common external objects like fishing gear, or alternatively, if this is not possible, to as far as possible ensure that the active function is not impaired by such events. Req priority: Medium Test status: Not performed Req status: Reviewed --------------------------------------------------------------------------------Req00xx

Use COTS Components The system should as far as possible be designed using readily available, proven COTS components. Req priority: Low Test status: Not performed Req status: Reviewed --------------------------------------------------------------------------------Req00xx

Ease of Assembly/Disassembly The system shall be designed to be easy to assemble/disassemble into replaceable units.

Appendix D: System Requirements Document

123

Req priority: Medium Test status: Not performed Req status: Reviewed --------------------------------------------------------------------------------Req00xx

Replaceable Units The system shall be split into well defined replaceable units. Req priority: High Test status: Not performed Req status: Reviewed --------------------------------------------------------------------------------Req00xx

Fail-Safe Priority The system shall in prioritised sequence implement the fail-safe principles below: 1. Prevent hazard to personnel 2. Prevent equipment damage 3. Enable continued production Req priority: High Test status: Not performed Req status: Reviewed D.4.2.10

Human Factors

--------------------------------------------------------------------------------Req00xx

Outdoor User Interface—Readability The system should ensure that control device labels, symbols, text and other information required in outdoor area during operation has a font size, contrast and, if applicable, illumination enabling the operator to easily read it with normal eyesight both in daylight and artificial light. Req priority: Medium

124

Test status: Req status:

Appendix D: System Requirements Document

Not performed Reviewed

D.5 Verification A test specification shall be made to detail the verification of the system requirements. Table D.4 lists the verification methods that are proposed for each requirement.

D.6 Traceability

Code

Name

Req priority

Req status

Stakeholder Req

Req00xx

Tagging of unit

Medium

Reviewed

Req00xx

SW version retrievable

Medium

Reviewed

Req00xx

System status monitoring

Medium

Reviewed

Req00yy

Req00xx

Configuration of system parameters

Medium

Reviewed

Req00yy Req00yy Req00yy

Req00xx

Lifting points

Medium

Reviewed

Req00yy

Req00xx

Single point of failure

Medium

Reviewed

Req00yy

Req00xx

Hot-swap

Medium

Reviewed

Req00yy

Req00xx

Hot swap xxx computer

Medium

Reviewed

Req00yy

Req00xx

Battery capacity (UPS)

Medium

Reviewed

Req00xx

Log key system events

High

Reviewed

Req00xx

Operator safety—sharp edges

Low

Reviewed

Req00yy

Req00xx

Operator safety—squeezing

Medium

Reviewed

Req00yy

Req00xx

Maintenance—Online

Medium

Reviewed

Req00yy

Req00xx

Ease of access

Medium

Reviewed

Req00yy

Req00xx

Weight

Medium

Reviewed

Req00yy

Req00xx

Electro Magnetic Compatibility (EMC)

Medium

Reviewed

Req00yy

Req00xx

Material corrosion

High

Reviewed

Req00yy

Req00xx

Electrical noise

Medium

Reviewed

Req00yy

Req00xx

Protection against entanglement

Medium

Reviewed

Req00yy

Req00xx

Use COTS components

Low

Reviewed

Req00yy

Req00xx

Ease of assembly/disassembly

Medium

Reviewed

Req00yy

Req00xx

Replaceable units

High

Reviewed

Req00yy

Req00xx

Fail-safe priority

High

Reviewed

Req00yy (continued)

Appendix D: System Requirements Document

125

(continued) Code

Name

Req priority

Req status

Req00xx

Redundant power supply

Medium

Reviewed

Stakeholder Req

Req00xx

Redundant communication lines

Medium

Reviewed

Req00xx

Outdoor user interface—readability

Medium

Reviewed

Req00xx

SW upgrade

Medium

Reviewed

Req00xx

SW components—compatibility

High

Reviewed

Req00xx

Build space for equipment—instrument room

Medium

Reviewed

Req00xx

Power supply from xxx

Medium

Reviewed

Req00xx

Temperature range—operation

Medium

Reviewed

Req00yy

Req00xx

Temperature range—storage

Medium

Reviewed

Req00yy

Req00xx

Enclosure protection—IP code

Medium

Reviewed

Req00xx

Tools

Low

Reviewed

Req00xx

Material degradation

Medium

Reviewed

Req00xx

Hazardous materials

Medium

Reviewed

Req00xx

Battery removal

Medium

Reviewed

Req00xx

RoHS—Restriction of Hazardous Substances Directive

Medium

Reviewed

Req00yy

Req00yy

✓ ✓ ✓

Enclosure protection—IP code

Fail-safe priority

Hazardous materials

✓

Material degradation ✓

✓

Material corrosion

Operator safety—sharp edges

✓

Maintenance—Online

✓

✓

Lifting points

Log key system events

✓

Hot-swap

Hot swap xxx computer

✓

Electro Magnetic Compatibility (EMC)

✓

✓

✓

Electrical noise

✓

✓

Ease of assembly/disassembly

✓

Inspection and reviewed

Ease of access

✓

Demonstration

✓

✓

Analysis

Verification method

Configuration of system parameters

Build space for equipment—instrument room

Battery removal

Battery capacity (UPS)

Requirement

Table D.4 List of requirement verification methods Not applicable

Similarity

Simulation

(continued)

✓

✓

✓

Test

126 Appendix D: System Requirements Document

✓

✓ ✓

Operator safety—squeezing

Outdoor user interface—readability ✓ ✓ ✓ ✓ ✓

Protection against entanglement

Redundant communication lines

Redundant power supply

Replaceable units

RoHS—Restriction of Hazardous Substances Directi…

Test

✓ ✓ ✓

Tools

Use COTS components

✓

✓

Temperature range—storage

Weight

✓

✓

Temperature range—operation

✓

Tagging of unit

System status monitoring

Single point of failure

SW version retrievable

✓

✓

✓

Simulation

✓

Similarity

SW upgrade

Not applicable

SW components—compatibility ✓

✓

Power supply from xxx

✓

Inspection and reviewed

Analysis

Verification method Demonstration

Requirement

Table D.4 (continued)

Appendix D: System Requirements Document 127

128

Appendix D: System Requirements Document

References 1. NORSOK M-001:2014. Material Selection. https://online.standard.no/norsokm-001-2014 2. NORSOK M-503:2016+AC:2018. Cathodic Protection. https://online.standard. no/norsok-m-503-2016ac-2018

Appendix E

System Requirement Document Template

© The Editor(s) (if applicable) and The Author(s), under exclusive license to Springer Nature Switzerland AG 2023 B. K. Datta, Fast-track Innovation and Commercialization: Tools and Techniques, https://doi.org/10.1007/978-3-031-30375-3

129

130

Appendix E: System Requirement Document Template

THIS PAGE IS INTENTIONALLY BLANK

Appendix E: System Requirement Document Template

131

CHANGE HISTORY Change

Version

Date

132

Appendix E: System Requirement Document Template

THIS PAGE IS INTENTIONALLY BLANK

Appendix E: System Requirement Document Template

133

Guidance: The Systems Requirements Document (SRD) translates warfighter Capability Based Requirements into performance based acquisition requirements for a system or subsystem in any program milestone or phase. This template provides guidance for preparation of the SRD using established Systems Engineering processes. Determine whether FOUO is applicable per DoDM 5200.01, Volume 4, “DoD Information Security Program: Controlled Unclassified Information (CUI),” February 24, 2012. Guidance Source: http://www.dtic.mil/whs/directives/corres/pdf/520001_vol4.pdf. Instructions: PEO-specific instruction will be added here. References: Input Document References; MIL-HDBK-520, Systems Requirements Document Guidance, 5 March 2010. Contents 1.

2.

3.

SCOPE ....................................................................................................................................134 1.1.

System Identification........................................................................................................135

1.2.

System Overview .............................................................................................................135

1.3.

System Requirements Document Overview ....................................................................135

APPLICABLE DOCUMENTS ..............................................................................................135 2.1.

General .............................................................................................................................136

2.2.

Government Documents ...................................................................................................136

2.2.1.

Specifications, Standards, and Handbooks ...............................................................136

2.2.2.

Other Government Documents, Drawings, and Publications ...................................137

2.3.

Non-government Publications ..........................................................................................138

2.4.

Order of Precedence ...........................................................................................................138

REQUIREMENTS ..................................................................................................................139 3.1.

Required States and Modes ..............................................................................................139

3.2.

System Capability Requirements .....................................................................................140

3.2.1. 3.3.

System Capability ..................................................................................................... ... 140

System External Interface Requirements ......................................................................... ....... 140

3.3.1.

Interface Identification and Diagrams ...................................................................... .... 140

3.3.2.

Project Unique Interface Identifier .........................................................................141

3.4.

System Internal Interface Requirements ..........................................................................142

3.5.

System Internal Data Requirements .................................................................................142

3.6.

Adaptation Requirements .................................................................................................142

3.7.

Safety Requirements ........................................................................................................142

3.8.

Security and Privacy Requirements .................................................................................143

134

Appendix E: System Requirement Document Template

3.9.

System Environment Requirements ...............................................................................143

3.10.

4.

Computer Hardware Requirements .....................................................................144

3.10.2.

Computer Hardware Resource Utilization Requirements ...................................144

3.10.3.

Computer Software Requirements ......................................................................144

3.10.4.

Computer Communications Requirements .........................................................144

3.11.

System Quality Factors ...............................................................................................145

3.12.

Design and Construction Contraints ...........................................................................145

3.13.

Personnel Related Requirements ................................................................................146

3.14.

Training Related Requirements ..................................................................................146

3.15.

Logistics Related Requirements .................................................................................146

3.16.

Other Requirements ....................................................................................................147

3.17.

Packaging Requirements ............................................................................................147

3.18.

Statutory, Regulatory, and Certification Requirements..............................................147

3.18.1.

Statutory Requirements .......................................................................................147

3.18.2.

Regulatory Requirements ....................................................................................147

3.18.3.

Certification Requirements .................................................................................148

3.19.

Precedence and Criticality of Requirements ..............................................................148

3.20.

Demilitarization and Disposal ....................................................................................148

VERIFICATION PROVISIONS ..........................................................................................148 4.1.

5.

6.

Computer Resource Requirements .............................................................................143

3.10.1.

Verification Methods......................................................................................................149

4.1.1.

Demonstration .........................................................................................................149

4.1.2.

Test ..........................................................................................................................149

4.1.3.

Analysis...................................................................................................................149

4.1.4.

Inspection ................................................................................................................149

4.1.5.

Special Verification Methods .................................................................................149

REQUIREMENTS TRACEABILITY..................................................................................150 5.1.

Traceability to Capability Document or System Specification ......................................150

5.2.

Traceability to Subsystems Requirements .....................................................................150

APPENDIX SECTION .........................................................................................................150 6.1.

Appendix A - Acronyms and Definitions ......................................................................150

6.2.

Appendix B - Key Performance Parameters/Key System Attributes .............................151

6.3.

Appendix C - Requirements Traceability Matrices........................................................151

6.4.

Appendix D - Verification Matrices...............................................................................151

E.1 Scope Click here to enter text.

Appendix E: System Requirement Document Template

135

Guidance: This paragraph contains a full identification of the system or subsystem and associated software to which this document applies, including as applicable, identification number(s), title(s), abbreviation(s), and release number(s) where known.

E.1.1 System Identification Click here to enter text. Guidance: This paragraph contains a full identification of the system or subsystem and associated software to which this document applies, including as applicable, identification number(s), title(s), abbreviation(s), and release number(s) where known.

E.1.2 System Overview Click here to enter text. Guidance: This paragraph briefly states the purpose of the system or subsystem and associated software to which this document applies. It describes the general nature of the system or subsystem and software; summarizes history of system development, operation, and maintenance; identifies project sponsor, acquirer, warfighter, developer, and support agencies; identifies current and planned operating sites; and lists other relevant documents.

E.1.3 System Requirements Document Overview Click here to enter text. Guidance: This paragraph summarizes the purpose and contents of this document and describes any security or privacy considerations associated with its use.

E.2 Applicable Documents Click here to enter text.

136

Appendix E: System Requirement Document Template

Guidance: This section lists the number, title, revision, and date of all documents referenced herein. This section also identifies the source for documents not available through normal Government stocking activities.

E.2.1 General Click here to enter text. Guidance: Provide an overview of documentation section. The following statement should be placed in all SRD documents and resulting specifications: “Documents listed in this section are specified in Sects. 3, 4, or 5 of this SRD. This section does not include documents cited in other sections of this specification or recommended for additional information or as examples. While every effort has been made to ensure the completeness of this list, document warfighter’s are cautioned that they should meet all specified requirements of documents cited in Sects. 3, 4, or 5 of this specification, whether or not they are listed.”

E.2.2 Government Documents Click here to enter text. Guidance: List applicable Government documentation.

E.2.2.1

Specifications, Standards, and Handbooks

Click here to enter text. Guidance: List Government specifications, standards, and handbooks. The following statement should be placed in all SRD documents and resulting specifications: “The following specifications, standards, and handbooks form a part of this document to the extent specified herein. Unless otherwise specified, the issues of these documents are those cited in the solicitation or contract.” Department of Defense Standards MIL-STD-961—Department of Defense Standard Practice Defense and ProgramUnique Specifications Format and Content Department of Defense Handbooks MIL-HDBK-61—Configuration Management Guidance MIL-HDBK-881—Work Breakdown Structures for Defense Materiel Items

Appendix E: System Requirement Document Template

137

(Copies of these documents are available online at https://assist.daps.dla.mil/qui cksearch/ or from the Standardization Document Order Desk, 700 Robbins Avenue, Building 4D, Philadelphia, PA 19,111–5094.)

E.2.2.2

Other Government Documents, Drawings, and Publications

Click here to enter text. Guidance: List other Government documents, drawings, and publications. The following statement should be placed in all SRD documents and resulting specifications: “The following other Government documents, drawings, and publications form a part of this SRD to the extent specified herein. Unless otherwise specified, the issues of these documents are those cited in the solicitation or contract.” Air Force Instructions AFI10-601—Capabilities Based Requirements Development AFI10-604—Capabilities Based Planning AFI61-204—Disseminating Scientific and Technical Information AFI63-101—Acquisition and Sustainment Life Cycle Management AFI63-1201—Life Cycle Systems Engineering AFI99-103—Capabilities Based Test and Evaluation AFMCI 99-103—Test Management (Copies of these documents are available online at http://www.e-publishing.af.mil/.) Chairman of the Joint Chiefs of Staff Instruction CJCSI 3170.01—Joint Capabilities Integration and Development System JCIDS Manual—Manual for the Joint Capabilities Integration and Development System (Copies of these documents are available online at http://www.dtic.mil/cjcs_directi ves/cjcs/instructions.htm.) Data Item Description (DID) DI-IPSC-81431—System/Subsystem Specification (SSS) (Copies of this document are available online at https://assist.daps.dla.mil/quicks earch/ or from the Standardization Document Order Desk, 700 Robbins Avenue, Building 4D, Philadelphia, PA 19,111–5094.) Department of Defense Directives and Instructions DoDD 5000.01—The Defense Acquisition System DoDI 5000.02—Operation of the Defense Acquisition System DoD 5200.1-PH—DoD Guide to Marking Classified Documents DoD 5200.1R—Information Security Program DoDD 5230.34—Distribution Statements on Technical Documents

138

Appendix E: System Requirement Document Template

DoDD 5230.35—Withholding of Unclassified Technical Data from Public Disclosure DoDD 8320.02—Data Sharing in a Net Centric Department of Defense DoDD 8500.01—Information Assurance (IA) DoDI 8500.2—Information Assurance (IA) Implementation (Copies of these documents are available online at http://www.dtic.mil/whs/direct ives/.)

E.2.3 Non-government Publications Click here to enter text. Guidance: List non-Government publications. The following statement should be placed in all SRD documents and resulting specifications: “The following documents form a part of this document to the extent specified herein. Unless otherwise specified, the issues of these documents are those cited in the solicitation or contract.” (List where copies of these documents can be found.) Institute of Electrical and Electronics Engineers (IEEE) IEEE STD 610.12—Standard Glossary of Software Engineering Terminology. IEEE STD 1220-2005—(ISO/IEC 26702), Application and Management of the Systems Engineering Process IEEE STD 1471-2000—Systems and Software Engineering—Recommended Practice for Architectural Description of Software Intensive Systems (Application for copies should be addressed to the IEEE Service Center, P.O. Box 1331, 445 Hoes Lane, Piscataway, NJ 08,855–1331, or online at http://www. ieee.org/portal/site.)

E.2.4 Order of Precedence Click here to enter text. Guidance: The following statement should be placed in all SRD documents and resulting specifications: “Unless otherwise noted herein or in the contract, in the event of a conflict between the text of this document and the references cited herein (except for related specification sheets), the text of this document takes precedence. Nothing in this document, however, supersedes applicable laws and regulations unless a specific exemption has been obtained.” [The parenthetical phrase “(except for related specification sheets)” is omitted from the paragraph for specifications that do not have related specification sheets.]

Appendix E: System Requirement Document Template

139

E.3 Requirements Click here to enter text. Guidance: This section identifies the basic system or subsystem requirements needed by the warfighter. This section is divided into the following paragraphs to specify system or subsystem requirements, e.g., those characteristics of the system or subsystem that are conditions for its acceptance. Each requirement should be assigned a project-unique identifier (to support testing and traceability), and should be stated in such a way that an objective verification can be defined for it. Project unique identifiers should use the Program Work Breakdown Structure (PWBS) pre contract award and the Contract Work Breakdown Structure (CWBS) post contract award. Each requirement should be annotated with associated qualification method(s) (see Sect. 4) and, for subsystems, traceability to system requirements (see Sect. 5.a), if not provided in those sections. The degree of detail to be provided is guided by the following rule: Include those characteristics of the system or subsystem that are conditions for system or subsystem acceptance; defer to design descriptions those characteristics an acquirer is willing to leave up to the developer. If there are no requirements in a given paragraph, the paragraph should so state. If a given requirement fits into more than one paragraph, it may be stated once and referenced from the other paragraphs. Each SRD KPP and KSA should have an associated threshold and objective. Attributes should include thresholds and objectives as applicable. The symbols used are: T Threshold—Minimum requirement level. O Objective—Desired requirement level. T = O Threshold and Objective are the same requirement level. No effort will be expended to exceed the Threshold requirement. Key Performance Parameters (KPPs) and Key System Attributes (KSAs) are identified in the body of Sect. 3 and provided in a tabular format ranked in order of importance in Appendix B.

E.3.1 Required States and Modes Click here to enter text. Guidance: If a system or subsystem is required to operate in more than one state or mode having requirements distinct from other states or modes, this paragraph identifies and defines each state and mode. Examples of states and modes include idle, ready, active, training, degraded, emergency, backup, wartime, or peacetime. The distinction between states and modes is arbitrary. A system or subsystem may be described in terms of states only, modes only, states within modes, modes within

140

Appendix E: System Requirement Document Template

states, or any other scheme that is useful. If no states or modes are required, this paragraph should so state, without the need to create artificial distinctions. If states and/or modes are required, each requirement or group of requirements in this specification should be correlated to the states and modes. The correlation may be indicated by a table or other method in this paragraph, in an appendix referenced from this paragraph or by annotation of the requirements in the paragraphs where they appear.

E.3.2 System Capability Requirements Click here to enter text. Guidance: This paragraph is divided into subparagraphs to itemize requirements associated with each system or subsystem function. A “function” is defined as a group of related requirements (e.g., avionics subsystem requirements).

E.3.2.1

System Capability

Click here to enter text. Guidance: This paragraph itemizes requirements associated with each system or subsystem function. If the function can be more clearly specified by dividing it into constituent functions, (e.g., avionics can be broken down into mission/operational definition, characteristics, design and construction, characteristics of subordinate elements, etc.,) the constituent functions should be specified in subparagraphs. Paragraphs 3.3.1 thru 3.3.2 provide a list of topics to be considered when specifying requirements regarding inputs the system accepts and outputs it produces.

E.3.3 System External Interface Requirements Click here to enter text. Guidance: This paragraph is divided into subparagraphs to specify requirements, if any, for the system’s or subsystem’s external interfaces. This paragraph may reference one or more Interface Requirements Specifications (IRSs) or other documents containing these requirements.

E.3.3.1

Interface Identification and Diagrams

Click here to enter text.

Appendix E: System Requirement Document Template

141

Guidance: This paragraph identifies required external system or subsystem interfaces. Identification of each interface includes a project unique identifier and designates interfacing entities (systems, configuration items, warfighters, etc.) by name, number, version, and documentation references, as applicable. The identification states which entities have fixed interface characteristics (and therefore impose interface requirements on interfacing entities) and which are being developed or modified (thus having interface requirements imposed on them).

Interface Diagram Click here to enter text. Guidance: Provide one or more interface diagrams to depict the interfaces.

E.3.3.2

Project Unique Interface Identifier

Click here to enter text. Guidance: This paragraph (beginning with 3.3.2) identifies a system or subsystem external interface by project-unique identifier, identifies interfacing entities, and is divided into subparagraphs as needed to state requirements imposed on the system or subsystem to achieve the interface. Interface characteristics of other entities involved in the interface are stated as assumptions or as “When [the entity not covered] does this, the system shall ….,” not as requirements on the other entities. This paragraph may reference other documents (e.g., data dictionaries, standards for communication protocols, and standards for warfighter interfaces) in place of stating the information here. Requirements include the following, as applicable, presented in any order suited to the requirements, and note any differences in these characteristics from the point of view of the interfacing entities (e.g., different expectations about size, frequency, or other characteristics of data elements): Note: Detailed external interface elements may not be known during SRD development, in which case external interface requirements will be in broader, performance based terms. Also, external interfaces will be described in more detail in the architecture diagrams and Information Support Plan (ISP). In many instances, interface requirements are known in great detail as they are associated with current operational systems. Net Ready KPP requirements are also addressed herein. (a) Provide priority the system assigns to the interface. (b) Provide requirements on type of interface (e.g., real-time data transfer, storage and retrieval of data, etc.) to be implemented. (c) Provide required commercial or Government external interface standards for data information transfer. (d) Provide required external communication links.

142

Appendix E: System Requirement Document Template

E.3.4 System Internal Interface Requirements Click here to enter text. Guidance: This paragraph specifies requirements, if any, imposed on interfaces internal to the system or subsystem. If all internal interfaces are left to the design or to requirement specifications for system or subsystem components, this fact is so stated. If such requirements are to be imposed, paragraph 3.3 of this DID provide a list of topics to be considered.

E.3.5 System Internal Data Requirements Click here to enter text. Guidance: This paragraph specifies requirements, if any, imposed on data internal to the system or subsystem. Included are requirements, if any, on databases and data files to be included in the system. If all decisions about internal data are left to the design or to requirements specifications for system or subsystem components, this fact is so stated. If such requirements are to be imposed, paragraphs 3.3.x.c and 3.3.x.d of this DID provide a list of topics to be considered.

E.3.6 Adaptation Requirements Click here to enter text. Guidance: This paragraph specifies requirements, if any, concerning installationdependent data that the system or subsystem is required to provide (e.g., site dependent latitude and longitude) and operational parameters that the system is required to use that may vary according to operational needs (e.g., parameters indicating operation-dependent targeting constants or data recording).

E.3.7 Safety Requirements Click here to enter text. Guidance: This paragraph specifies system or subsystem requirements, if any, concerned with preventing or minimizing unintended hazards to personnel, property, and the physical environment. Examples include restricting use of dangerous materials; classifying explosives for purposes of shipping, handling, and storing;

Appendix E: System Requirement Document Template

143

abort/escape provisions from enclosures; gas detection and warning devices; grounding of electrical systems; decontamination; and explosion proofing. This paragraph includes system or subsystem requirements, if any, for nuclear components, including, as applicable, requirements for component design, prevention of inadvertent detonation, and compliance with nuclear safety rules.

E.3.8 Security and Privacy Requirements Click here to enter text. Guidance: This section specifies system or subsystem requirements, if any, concerned with maintaining security and privacy. The requirements include, as applicable, security/privacy environment in which the system or subsystem should operate, type and degree of security or privacy to be provided, security/privacy risks the system or subsystem should withstand, required safeguards to reduce those risks, security/privacy policy, security/privacy accountability the system or subsystem provides, and criteria for security/privacy certification/accreditation. Paragraphs should be included for IA requirements IAW DoDD 8500.01, Information Assurance (IA); and DoDI 8500.2, Information Assurance (IA) Implementation as required.

E.3.9 System Environment Requirements Click here to enter text. Guidance: This paragraph specifies requirements, if any, regarding the environment in which the system or subsystem operates. Examples for a software system or subsystem are computer hardware and operating system on which the software runs. (Additional requirements concerning computer resources are given in the next paragraph). Examples for a hardware-software system include environmental conditions that the system or subsystem withstands during transportation, storage, and operation, e.g., conditions in the natural environment (wind, rain, temperature, geographic location), induced environment (motion, shock, noise, electromagnetic radiation), and environments due to enemy action (explosions, radiation).

E.3.10 Computer Resource Requirements Click here to enter text.

144

Appendix E: System Requirement Document Template

Guidance: This paragraph is divided into the following subparagraphs. Depending upon the nature of the system or subsystem, computer resources covered in these subparagraphs may constitute the environment of the system or subsystem (as for a software system) or components of the system (as for a hardware-software system).

E.3.10.1

Computer Hardware Requirements

Click here to enter text. Guidance: This paragraph specifies requirements, if any, regarding computer hardware that is used by, or incorporated into, the system or subsystem. Requirements include, as applicable, number of each type of equipment, type, size, capacity, and other required characteristics of processors, memory, input/output devices, auxiliary storage, communications/network equipment, and other required equipment.

E.3.10.2

Computer Hardware Resource Utilization Requirements

Click here to enter text. Guidance: This paragraph specifies the requirements, if any, on the system’s or subsystem’s computer hardware resource utilization, e.g., maximum allowable use of processor capacity, memory capacity, input/output device capacity, auxiliary storage device capacity, and communications/network equipment capacity. Requirements (stated, for example, as percentages of the capacity of each computer hardware resource) include conditions, if any, under which the resource utilization is to be measured.

E.3.10.3

Computer Software Requirements

Click here to enter text. Guidance: This paragraph specifies requirements, if any, regarding computer software that is used by, or incorporated into, the system or subsystem. Examples include operating systems, database management systems, communications/network software, utility software, input and equipment simulators, test software, and manufacturing software. The correct nomenclature, version, and documentation references of each such software item are provided.

E.3.10.4

Computer Communications Requirements

Click here to enter text.

Appendix E: System Requirement Document Template

145

Guidance: This paragraph specifies additional requirements, if any, concerning computer communications that are used by, or incorporated into, the system or subsystem. Examples include geographic locations to be linked; configuration and network topology; transmission techniques; data transfer rates; gateways; required system use times; type and volume of data to be transmitted/received; time boundaries for transmission/reception/response; peak volumes of data; and diagnostic features.

E.3.11 System Quality Factors Click here to enter text. Guidance: This paragraph specifies requirements, if any, pertaining to system or subsystem quality factors. Examples include quantitative requirements concerning system functionality (ability to perform required functions), reliability (ability to perform with correct, consistent results, e.g., mean time between failure for equipment), maintainability (ability to be easily serviced, repaired, or corrected), availability (ability to be accessed and operated when needed), flexibility (ability to be easily adapted to changing requirements), portability of software (ability to be easily modified for a new environment), reusability (ability to be used in multiple applications), testability (ability to be easily and thoroughly tested), usability (ability to be easily learned and used), and other attributes.

E.3.12 Design and Construction Constraints Click here to enter text. Guidance: This paragraph specifies requirements, if any, that constrain design and construction of the system or subsystem. For hardware-software systems, this paragraph includes physical requirements imposed on the system or subsystem. These requirements may be specified by reference to appropriate commercial or military standards and specifications. Examples include requirements concerning: • Use of a particular system or subsystem architecture or requirements on the architecture, e.g., required subsystems; use of standard, military, or existing components; or use of Government furnished property (equipment, information, or software). • Use of particular design or construction standards; use of particular data standards; use of a particular programming language; use of existing software; workmanship requirements and production techniques. • Physical characteristics of the system or subsystem (such as weight limits, dimensional limits, color, protective coatings); interchangeability of parts; ability to be

146

• • • •

Appendix E: System Requirement Document Template

transported from one location to another; ability to be carried or set up by one or a given number of people. Materials that can and cannot be used; requirements on handling of toxic materials; limits on electromagnetic radiation that the system is permitted to generate. Use of nameplates, part marking, serial and lot number marking, and other identifying markings. Provision for flexibility and expandability to support anticipated areas of growth or changes in technology, threat, or mission. Manufacturing requirements and constraints associated with producing the system or subsystem to be included.

E.3.13 Personnel Related Requirements Click here to enter text. Guidance: This paragraph specifies the system or subsystem requirements, if any, included to accommodate the number, skill levels, duty cycles, training needs, or other information about the personnel who will use or support the system. Examples include requirements for the number of workstations to be provided and for built-in help and training features. Also included are human factors engineering requirements, if any, imposed on the system or subsystem. These requirements include, as applicable, considerations for capabilities and limitations of humans, foreseeable human errors under both normal and extreme conditions, and specific areas where effects of human error would be particularly serious. Examples include requirements for adjustableheight workstations, color and duration of error messages, physical placement of critical indicators or buttons, and use of auditory signals.

E.3.14 Training Related Requirements Click here to enter text. Guidance: This paragraph specifies the system or subsystem requirements, if any, pertaining to training. Examples include training devices and training materials to be included in the system.

E.3.15 Logistics Related Requirements Click here to enter text.

Appendix E: System Requirement Document Template

147

Guidance: This paragraph specifies the system requirements, if any, concerned with logistics considerations. These considerations may include system maintenance, software support, system transportation modes, supply-system requirements, impact on existing facilities, and impact on existing equipment.

E.3.16 Other Requirements Click here to enter text. Guidance: This paragraph specifies additional system or subsystem requirements, if any, not covered in the previous paragraphs. Examples include requirements for system or subsystem documentation, e.g., specifications, drawings, technical manuals, test plans and procedures, and installation instruction data, if not covered in other contractual documents.

E.3.17 Packaging Requirements Click here to enter text. Guidance: This section specifies the requirements, if any, for packaging, labeling, and handling the system or subsystem and its components. Applicable military specifications and standards may be referenced if appropriate.

E.3.18 Statutory, Regulatory, and Certification Requirements E.3.18.1

Statutory Requirements

Click here to enter text. Guidance: This paragraph specifies, if applicable, statutory requirements for the system or subsystem.

E.3.18.2

Regulatory Requirements

Click here to enter text. Guidance: This paragraph specifies, if applicable, regulatory requirements for the system or subsystem.

148

E.3.18.3

Appendix E: System Requirement Document Template

Certification Requirements

Click here to enter text. Guidance: This paragraph specifies, if applicable, certification requirements for the system or subsystem.

E.3.19 Precedence and Criticality of Requirements Click here to enter text. Guidance: This paragraph specifies, if applicable, order of precedence, criticality, or assigned weights indicating relative importance of requirements in this specification. Examples include identifying those requirements deemed critical to safety, to security, or to privacy for purposes of singling them out for special treatment. If all requirements have equal weight, this paragraph so states. Key Performance Parameters (KPPs) and Key System Attributes (KSAs) are identified in the body of Sect. 3 and provided in a tabular format ranked in order of importance.

E.3.20 Demilitarization and Disposal Click here to enter text. Guidance: Demilitarization and disposal at the end of a life-cycle include activities necessary to ensure disposal of decommissioned, destroyed, or irreparable system components meet applicable regulations, directives and environmental constraints.

E.4 Verification Provisions Click here to enter text. Guidance: This section defines a set of verification methods and specifies for each requirement in Sect. 3 the method(s) to be used to ensure the requirement has been met. A table is used to present this information and is documented in Appendix C. The SRD contains verification methods desired by the Government. A contractor may offer alternative verification methods with associated justification.

Appendix E: System Requirement Document Template

149

E.4.1 Verification Methods E.4.1.1

Demonstration

Click here to enter text. Guidance: Operation of the system, subsystem, or a part of the system that relies on observable functional operation not requiring use of instrumentation, special test equipment, or subsequent analysis.

E.4.1.2

Test

Click here to enter text. Guidance: Operation of the system, subsystem, or a part of the system, using instrumentation or other special test equipment to collect data for later analysis.

E.4.1.3

Analysis

Click here to enter text. Guidance: Processing of accumulated data obtained from other qualification methods. Examples are reduction interpolation, or extrapolation of test results.

E.4.1.4

Inspection

Click here to enter text. Guidance: Visual examination of system components, documentation, etc.

E.4.1.5

Special Verification Methods

Click here to enter text. Guidance: Special verification methods for the system or subsystem, e.g., special tools, techniques, procedures, facilities, acceptance limits, use of standard samples, preproduction or periodic production samples, pilot models, or pilot lots.

150

Appendix E: System Requirement Document Template

E.5 Requirements Traceability Guidance: For a system level SRD, this paragraph includes traceability requirements to a warfighter Capability Document and down to applicable subsystems. For a subsystem level SRD, this paragraph includes traceability to the system specification and down to applicable line replaceable units (LRUs), including software Operational Flight Programs (OFPs) or equivalent. Use of automated tools is highly encouraged and tools that maintain detailed artifacts of each requirement are preferred.

E.5.1 Traceability to Capability Document or System Specification Click here to enter text. Guidance: This paragraph contains a description of the traceability to a Capability Document or System Specification. It also defines associated attributes that an automated tool should capture to document each requirement.

E.5.2 Traceability to Subsystems Requirements Click here to enter text. Guidance: This paragraph contains a description of traceability to a subsystem or lower tiered requirement document. It also defines associated attributes that an automated tool should capture to document each requirement.

E.6 Appendix Section E.6.1 Appendix A—Acronyms and Definitions Click here to enter text. Guidance: This appendix contains acronyms and provides standard definitions for terminology used herein.

Appendix E: System Requirement Document Template

151

E.6.2 Appendix B—Key Performance Parameters/Key System Attributes Click here to enter text. Guidance: This appendix contains tabularized KPPs, and KSAs, if applicable, listed in prioritized order.

E.6.3 Appendix C—Requirements Traceability Matrices Click here to enter text. Guidance: This appendix contains tabularized requirements traceability to the source documentation and to the next lower tier documentation where known. If not known, pre contract award, lower tier traceability is to be included in the resultant system or subsystem specification.

E.6.4 Appendix D—Verification Matrices Click here to enter text. Guidance: This appendix contains tabularized verification method for every system or subsystem requirement. If not known, pre contract award, the verification method is to be included in the resultant system or subsystem specification.

Appendix F

A3 Template

© The Editor(s) (if applicable) and The Author(s), under exclusive license to Springer Nature Switzerland AG 2023 B. K. Datta, Fast-track Innovation and Commercialization: Tools and Techniques, https://doi.org/10.1007/978-3-031-30375-3

153

2. Breakdown the problem

Note :- notes in red are only for guidance on how to use the A3 document

3. Set the Goals Set measurable and realistic goals 1 2 3 4

present key features of the process problem in the form of : - Bar chart - line graph etc.

Draft a summary map of process, or schematic.

Understand the problem. Collect data related to the problem. Break down the problem into small components, so that it is easy to solve. How much of the total problem will be addressed at this point?

2. Breakdown the problem

Impact on target

Select the most practical and effective countermeasure(s). Create a clear and detailed action plan. Implement as fast as possible.

6. Pick Countermeasures & implement

6. Implement Countermeasure

5. Develop Countermeasures Countermeasures

Identify areas for improvement

Clarify the root cause. Consider as many potential causes as possible.

Why this is a problem? What is the problem? Who is interested in the problem? What is the benefit of solving this problem ? How does it help to address the goals of the business?

Open A3 in Excel Elect a leader Form the team (stakeholders) Train the team in the 8 step approach Identify all stakeholders Define the problem in terms of impact on the customer & stakeholders.

4. Analyse the Root Cause

Department

4. Analyse the Root cause

Stakeholders (name & role) 1. 2. 3. 4.

1. Clarify the problem

Team members (name & role) 1. 2. 3. 4.

1. Clarify the problem

Team Leader (name & phone)

A3 No. and Name

Document the new process and set as new standard. Share the new standard through deployment. Reflect and celebrate success.

8. Standardise & Share Success

8. Standardise & Share Success

Monitor progress and report findings to stakeholders. It may require more than one attempt to get the desired result. Mistakes are an important part of the learning process.

6. Monitor Results & report

7. Monitor Results & report

Start date & planned duration

Organisation objective

154 Appendix F: A3 Template

Appendix G

Risk Register

© The Editor(s) (if applicable) and The Author(s), under exclusive license to Springer Nature Switzerland AG 2023 B. K. Datta, Fast-track Innovation and Commercialization: Tools and Techniques, https://doi.org/10.1007/978-3-031-30375-3

155

Project risk

Intiated Risk Category (Tech.\External\Organisational\ Date Managmt\User)

Focus: Objective:

Risk ID

Project Name Project No.

Evaluated Source Risk Description Date

Risk Identification

Date

Risk Register

Risk Identifier (Raised by)

project.

1 - 5 ( 1 being the lowest)

(Probability)

Likelyhood of Occurence Impact of severity of Risk (Impact) 1-5 ( 1 being the lowest)

Risk analysis Score (P-I rating) (Value = P*I) ( Rating 10 or above must be addressed)

Planning

Indicators that a risk has Risk mitigation - Action Plan occurred or is about to occur. (Avoid\Transfer\Mitigate\Accept)

Trigger Responsibility( Comments Owner)

Status (Identified\Analysis complete\Planning complete\Triggered\Resolved\Retired)

Monitoring and Control

Note: Risk assesment will be performed at start of new project phase, and will be updated continuously. A preliminary risk assessment is given in this document, but is not limited to the points below. Mitigation plan will be incorporated in project management plan and followed up during the

Relevant ID's Present

156 Appendix G: Risk Register

Appendix G: Risk Register

157 P-I Score

High

5

Medium

3 2

Low

1

Probability

4

Impact 1 Negligible

2

3 Moderate

4

5 High

Index

A A3, 75, 79, 80, 157 Accelerated innovation, 51 Accidental innovation, 11 Adaptability, 55 Affordability, 55 Airbnb, 41, 42 Amazon, 41, 42 Analysis, 24, 61, 64, 67–71, 74, 77, 88, 117, 127, 128, 152 Animation, 75, 77 Applied research, 1, 6

B Basic research, 1, 6–8 Berkus method, 17 Blue ocean, 21–23 Breakthrough innovation, 1, 9, 15, 21 Business innovation, 1 Business model, 2, 3, 9, 15–17, 21, 39–41, 88–93 Business model canvas, 21, 39–43, 83, 87, 90, 91, 93, 103 Business strategy, 30, 40, 71, 76

C Classification of innovation, 1, 7 Commercialization, 30, 38, 39, 87–90, 92, 94 Concept development, 53, 57, 72, 76, 84 Concept development sheet, 53 Concurrent engineering, 45, 49, 50, 75 Copyright, 33, 34, 101 Cost-to-duplicate method, 18

Customer Acceptance Level (CAL), 45–47, 75, 82 Customer requirement, 57, 58, 64, 72 Cycle of knowledge creation, 75, 85

D Decision making tool, 79 Demonstration, 46, 68–70, 127, 128, 152 Derived requirement, 65 Design for manufacture, 78 Design innovation, 1 Design requirement, 65, 113 Disclosure of invention, 21, 33, 90 Discounted cash flow method, 17, 18 Disruptive innovation, 1, 9, 23, 40 3d printing, 75, 77, 78 Dynamic simulation, 75

E European Patent Office, 36

F Failure & Learning, 72 Fast track technology development, 75, 82 Flexibility, 13, 15, 55, 64, 84, 89, 148, 149 Freedom To Operate (FTO), 87 Functional requirement, 56, 63–65, 109, 115 Function means analysis, 53, 58, 60 Funding, 1, 16, 38, 90, 91, 94

© The Editor(s) (if applicable) and The Author(s), under exclusive license to Springer Nature Switzerland AG 2023 B. K. Datta, Fast-track Innovation and Commercialization: Tools and Techniques, https://doi.org/10.1007/978-3-031-30375-3

159

160 I Impact, 5, 6, 8, 11, 13, 15, 23, 38, 47, 56, 67, 73, 81, 82, 89, 91, 150 Incremental innovation, 1, 8, 9, 21, 22, 25, 89 Innovation, 1–5, 7–10, 12–15, 23, 24, 26, 32, 33, 36, 38, 40, 45, 47, 49, 51, 55, 76, 80, 87–90, 92 Innovation culture, 12 Innovation ecosystem, 1, 12, 15 Innovation management, 25, 26 Intellectual property, 21, 33, 34, 37, 38, 92, 101 Intellectual Property Rights (IPR), 21, 33–35, 38, 89, 90, 92, 101 International Council of Systems Engineering (INCOSE), 53, 85 Invention, 1, 3, 4, 6, 11, 12, 33–35, 37, 38, 47, 90, 92 Inventive steps, 4, 34

L LEAN, 75, 83 Licensing, 92 Life cycle integration, 54

M Market assessment, 38, 39, 87, 90 Marketing innovation, 10 Modularity, 55

N Net Present Value (NPV), 17–19 Non-disclosure agreement, 37, 99

O Operational requirements, 56, 58, 64, 65 Organisational innovation, 10 Organization for Economic Co-operation and Development (OECD), 3 Oslo Manual, 3

P Patent, 4, 13, 33–37, 39, 90, 101 Patent Cooperation Treaty (PCT), 35, 36 Patent Cooperation Treaty (PCT) application, 35, 36 Patenting process, 35 Performance requirement, 64, 65

Index P-I diagram, 81, 82 Pricing strategy, 21, 27, 28 Priority application, 35, 36 Probability, 36, 81, 92, 93 Process innovation, 1, 10 Product innovation, 10 Product life cycle, 21, 25, 26, 39 Profit, 5, 17, 21–26, 28, 39, 92 Pugh matrix, 53, 61, 62

Q Qualification of new technology, 75, 78, 79

R Red ocean, 21–23 Regulatory compliance, 56 Reliability, 56 Requirement analysis, 53, 64, 77 Requirement verification matrix, 53, 68, 69 Return on investment, 5, 18, 23, 91, 92, 94 Risk Register, 75, 81, 159 Root cause analysis, 80

S Scalability, 55 Simulation, 68, 69, 77, 127, 128 Simultaneous engineering, 51 Stake holders, 53, 110 Stanford Research Institute (SRI), 3 Start-ups, 1, 9, 15–19, 34, 36, 38, 87, 90, 92–94 Strategic innovation agenda, 1, 14 Sustainable innovation, 1, 4, 5 System design document, 53, 67, 68, 72, 77 System requirements document, 53, 63, 67, 106, 132, 138 Systems engineering, 53–55, 62, 71, 73–76, 84–86, 110 Systems engineering process, 53, 54, 63, 64, 71–73, 76, 86, 136, 141 System validation, 72

T Technology innovation, 1, 24 Technology Readiness Level (TRL), 38, 45, 46, 75, 82 Technology roadmap, 30, 31 Test, 9, 12, 46, 66–72, 77, 79, 83, 115, 117, 126–128, 140, 148, 150, 152, 153 Testability, 55, 148

Index Time to market, 21, 39, 49, 50, 91 Traceable, 60, 85 Trademark, 33, 34, 101 U Uber, 10, 29, 41, 43 Unique selling point, 28, 29 Unique selling proposition, 90, 91 V Validation plan, 53

161 Valley of death, 38 Valuation of startups, 1, 17, 18 Value creation, 21, 23, 24, 33 Value of systems engineering, 86 Value proposition, 21–23, 27–29, 38, 40, 41, 87, 90

W Waterfall model, 45, 49 World Intellectual Property Organization (WIPO), 33