Improvement of project lines coordination: a case study of automotive R&D innovation

Universidade do Minho Escola de Engenharia Renato Teixeira Araújo de Matos Pinto Improvement of Project Lines Coordination: a case study of automotive R&D innovation June 2021 Renato T. Pinto UMinho | 2021 Improvement of Project Lines Coordination: a case study of automotive R&D innovation June 2021 June 2021 33 Renato Teixeira Araújo de Matos Pinto Improvement of Project Lines Coordination: a case study of automotive R&D innovation Master’s Thesis Master’s in Engineering Project Management Work done under the guidance of: Professor Anabela Pereira Tereso Doctor João Manuel Peixoto Faria ii DIREITOS DE AUTOR E CONDIÇÕES DE UTILIZAÇÃO DO TRABALHO POR TERCEIROS Este é um trabalho académico que pode ser utilizado por terceiros desde que respeitadas as regras e boas práticas internacionalmente aceites, no que concerne aos direitos de autor e direitos conexos. Assim, o presente trabalho pode ser utilizado nos termos previstos na licença abaixo indicada. Caso o utilizador necessite de permissão para poder fazer um uso do trabalho em condições não previstas no licenciamento indicado, deverá contatar o autor, através do RepositóriUM da Universidade do Minho. Licença concedida aos utilizadores deste trabalho Atribuição CC BY https://creativecommons.org/licenses/by/4.0/ iii ACKNOWLEDGEMENT This work would not have been possible without the reassuring support of many people, whom I would like to thank in no particular order. To my advisor, Professor Anabela Tereso, for the trust bestowed in me, for her continued availability and counseling throughout the past year, I owe my deepest gratitude and respect. This feeling I would like to extend to Doctor João Faria, for his mindful revisions of this essay. To my mentor and manager at Bosch, Victor Saraiva, I am most thankful too, for welcoming me at the company, to his team and allowing me this unique lesson in project management. To Bosch CC-PS Braga and its many associates, particularly those who I have crossed paths with on innovation, I want to leave my appreciation and wishes of best success. I remain forever indebted to my parents, unwavering supporters of my search for new knowledge and meanings in life. To my brothers, André and Fredy, for their steady companionship and help in keeping the starkest effects of quarantine at bay. To my dearest friends, Bruno and Sofia, whose company at movies and board games I cannot appreciate enough. iv INTEGRITY STATEMENT I hereby declare having conducted this academic work with integrity. I confirm that I have not used plagiarism or any form of undue use of information or falsification of results along the process leading to its elaboration. I further declare that I have fully acknowledged the Code of Ethical Conduct of the University of Minho. v ABSTRACT Improvement of Project Lines Coordination: a case study of automotive R&D innovation The automotive industry is one marked by constant remodeling. A long road has been paved since electrical and internal combustion engines were invented, at the turn of the XIX century, and many more technological breakthroughs have since preceded this century’s challenges. The driving force beyond such human prowess is innovation. Therefore, for companies like Robert Bosch GmbH to thrive, knowing how to innovate is key to harness present-day opportunities. Bosch’s Chassis System Control, through its R&D department, has been focused on sensory technology for autonomous driving. New knowledge is furthered by the division’s portfolio, which includes Sensible Car (SC), a joint innovation program with the University of Minho. The primary goal of this research is to bring the rationale of Project Management (PM) to the aid of twelve subprojects within SC. To put it to use, this innovation context is depicted through a case study research strategy. Participant observation, document analysis, informal interviews and a questionnaire are used to check the projects’ formal and informal processes. This account portrays how the perception of the project environment influences the ability to fulfill its innovative purposes. The main issues found concern scope, resource and communication management. These were addressed through servant leadership, with the researcher assuming enabling traits of a facilitator in a functionalized project structure. A new take on communication management was produced to help align the project structure and stricter role definition is recommended to further project integration. The chance to adopt a hybrid project management life cycle, beside the traditional high-level program controls, was identified too. The produced insights serve to understand how agile, classical or hybrid PM configurations might emerge from the complex interaction of human and technological agents. KEYWORDS Automotive, Innovation, Innovation Management, Project Management vi RESUMO Improvement of Project Lines Coordination: a case study of automotive R&D innovation A indústria automóvel está em constante renovação. Desde a invenção de motores elétricos e de combustão interna no final do século XIX, muitos foram os avanços tecnológicos que vieram preceder os desafios da atualidade. A força motriz por detrás deste percurso é a inovação. Para empresas como a Robert Bosch GmbH, saber inovar é, portanto, essencial para capitalizar as oportunidades do presente. A sua divisão de Chassis System Control, através do seu departamento de I&D, tem-se focado em tecnologia de sensores para a condução autónoma. A produção de novo conhecimento é conduzida pelo portefólio da divisão, que inclui o Sensible Car (SC), um programa de inovação copromovido com a Universidade do Minho. O objetivo principal desta investigação é colocar a dialética da Gestão de Projeto (GP) ao serviço de doze subprojetos do SC. Para tal, o contexto de inovação é retratado através de um caso de estudo. Observação participante, análise documental, entrevistas informais e um questionário são usados para sondar os processos formais e informais do projeto. Este trabalho demonstra como a perceção do ambiente de projeto influencia a capacidade de cumprir com o propósito inovador. As principais limitações identificadas concernem a gestão de âmbito, recursos e comunicação. A resposta a estas partiu de uma abordagem de servant leadership , com o investigador a assumir o papel de facilitador junto de uma estrutura de projeto funcional. É proposta uma nova abordagem à gestão da comunicação para auxiliar o alinhamento do projeto, sendo recomendada mais definição de papéis para aprofundar aspetos de integração. Foi também identificada a possibilidade de adotar um ciclo de gestão de vida do projeto híbrido, a par dos mecanismos tradicionais de controlo de alto-nível para o programa. As reflexões obtidas permitem perceber como modelos ágeis, clássicos ou híbridos de GP podem emergir da interação complexa de fatores humanos e tecnológicos. PALAVRAS-CHAVE Gestão de Inovação, Gestão de Projeto, Indústria Automóvel, Inovação vii INDEX Acknowledgement .............................................................................................................................. iii Abstract............................................................................................................................................... v Resumo.............................................................................................................................................. vi Index ................................................................................................................................................. vii Figure Index ....................................................................................................................................... ix Table Index ......................................................................................................................................... xi Abbreviations and Acronyms .............................................................................................................. xii 1. Introduction ................................................................................................................................ 1 1.1 Background & motivation .................................................................................................... 1 1.2 Research goals .................................................................................................................... 3 1.3 Research design .................................................................................................................. 3 1.4 Thesis structure .................................................................................................................. 4 2. Literature Review ........................................................................................................................ 6 2.1 Project management ........................................................................................................... 6 2.1.1 Agile project management ........................................................................................... 8 2.1.2 Classic project management and PMLC ..................................................................... 19 2.1.3 Hybrid project management ....................................................................................... 22 2.2 Innovation projects ............................................................................................................ 25 2.2.1 Innovation typology .................................................................................................... 25 2.2.2 Innovation project factors and features ....................................................................... 27 2.2.3 Practices in managing innovation projects .................................................................. 32 2.3 Summary of literature review ............................................................................................. 39 3. Research Methodology .............................................................................................................. 40 3.1 Research strategy .............................................................................................................. 40 3.2 Data collection .................................................................................................................. 41 3.3 Data analysis .................................................................................................................... 45 4. Case Study ............................................................................................................................... 46 4.1 Company presentation ...................................................................................................... 46 1 1. INTRODUCTION This introductory chapter comprises some premises on innovation and project management concepts, describes this thesis development context, its goals and the research design choices addressing the issues it faces. The document overall structure is also presented. 1.1 Background & motivation Innovation has a pivotal role in ensuring long-term business sustainability and growth. Whereas some companies abide by market trends, others actively seek to expand their business portfolio. It is by entering new markets or further strengthening their control over core business that the latter effectively alter the competitive landscape. Moreover, innovation might be said of an incremental kind or encompass groundbreaking, disruptive change brought on by new technologies, services or processes (Dodgson, Gann, & Salter, 2008). When companies commit to develop innovative solutions, they often dwell in uncharted waters. Therefore, it is expectable for the management of innovation projects to set forth plenty of challenges. These can range from a broadly defined scope, to large, entrepreneurial, multicultural team and work environments. In such contexts, neither project performance nor research and development (R&D) investment will directly translate into financial or, likewise, easily quantifiable value (Tellis, Prabhu, & Chandy, 2009). Innovation endeavor thrives in so-called innovation clusters, a concept drawn from the business cluster as defined by Porter (1998) at the turn of the century. The cluster environment, which may include both public and private entities, is the stage for cross-functional, intercompany projects, with particular managerial needs. The triple helix model, first proposed by Leydesdorff and Etzkowitz (1998), describes how academia, industry and government have come together to shape innovation systems. Project Management (PM), in its turn, proves a valuable tool in catalyzing the expectable benefits from such university-industry collaborations (Barnes, Pashby, & Gibbons, 2002; Fernandes, O’ Sullivan, Pinto, Araújo, & Machado, 2020). Nowadays, there are several pathways to PM, such as the widely known Project Management Body of Knowledge - PMBOK (PMI, 2017a) process-based approach, which breaks down the project lifecycle into five groups: initiating, planning, executing, monitoring and controlling, and closing. This type of partition resembles that of traditional, more classical methods that go by names such as waterfall, Stage-Gate (Cooper, 1990) or phase-based approaches. Because these rely on the upfront collection of requirements 2 and laborious planning, they are often seen as opposed to agile methods. Indeed, agile frameworks, being less formal approaches, may prove the best suit to face innovative “high-uncertainty projects (that) have high rates of change, complexity, and risk”. They have developed “to explore feasibility in short cycles and quickly adapt based on evaluation and feedback” (PMI, 2017b, p. 7). Even though in recent years Agile Project Management (AgPM) has been the emerging standard for project execution, one should bear in mind there is no ready solution for any given organizational context. In truth, plenty of researchers and authors advocate and report on the need for tailoring the PM practice to individual project characteristics, using traditional, agile or hybrid approaches (Burgan & Burgan, 2014; Meredith, Shafer, & Mantel, 2017). Given its ground-breaking nature, it must be considered that innovation projects are likely to be of high complexity. Such complexity may arise from things like the number of parts, the number of subsystems, the number of involved teams and organizations, or the existence of technological voids. Uncertainty must also be accounted for when considering the project and team autonomy in complex stakeholder environments. Project perception among its sponsors and mid-management, within one or among several interacting organizational hierarchies, influences both the effectiveness of decision-making processes and goal congruency (Jensen, Johansson, & Löfström, 2006). This can be quite detrimental for large, cross-institutional innovation projects, which are purposely created to facilitate communication and knowledge exchange between complementing individual and group competencies (Hoegl & Parboteeah, 2006). This master thesis in Engineering Projects Management took place at Bosch Car Multimedia S.A., a company of the BOSCH Group, located in Braga, Portugal. Within Bosch Mobility Solutions Business Sector, its Chassis Systems Control division (CC-PS) has traditionally been supplying automotive Original Equipment Manufacturers with so-said classical sensors, which regulate and assist vehicle steering and directional control (Robert Bosch S.A., 2019). Presently, the push for automated and safer driving has given way to several innovation initiatives, including the Sensible Car program (SC), which kicked-off mid-2018. SC enrolls some other entities, namely the Co-promoter, University of Minho (UM). The involved third parties include the Iberian Nanotechnology Laboratory (INL), Instituto de Telecomunicações (IT), Innovation Hub in Polymer Engineering (PIEP) and the Center for Computer Graphics (CCG). This implies that intercompany teamwork takes place within the program’s scope. Then, for LiDAR, which is a subset of 12 project lines within SC, the need for further team integration was identified. 3 1.2 Research goals The main goal of this research is to improve team integration among SC.LiDAR 12 project lines. The corresponding research question can be formulated: What issues affect SC.LiDAR project lines coordination and how to address them? After a preliminary assessment of project reality, this question can be further divided into a more detailed goal subset. This research purpose would hereby translate to: • Help SC.LiDAR teams to identify, define and agree on final deliverable(s) requirements. • Improve team communication and draw out team interdependencies. • Implement PM tools or PM methodologies for team coordination. 1.3 Research design To address the aforementioned, the research strategy will be that of a case study. The case study allows bridging observed project specifics with the abstract concepts lying at the core of the issues it faces (Neuman, 2011). PM standards, in their turn, can provide the coding to such concept characterization, thus permitting a more structured approach to issue decomposition and resolution. While looking for patterns and themes across the gathered data, moving from specific circumstance to general realization, this research focus will be so determined and redirected, accordingly. According to Flick (2015) this is characteristic of an inductive approach. While deduction aims to provide a certain reason for a given phenomenon, induction delivers a plausible or likely conclusion. Saunders et al. (2016) place typically inductive approaches within the philosophical domain of interpretivism. This philosophy acknowledges that the project environment is a social construct, where language and culture shape different interpretations, where complex and multiple realities coexist. This research is therefore anchored on perception and interpretation, i.e., the researcher’s narrative becomes part of what is researched and subjective. The present study resorts to a multi-method qualitative research design, with a cross-sectional time horizon. It is to say that methods such as observation, document analysis, surveys and informal interviews (e.g. project meetings) will be applied at discrete moments in time. Figure 1 shows the correlation between these data collection techniques, the case study strategy, and the wider philosophical approach. 4 Figure 1 - Saunders’ diagram (research onion) with this work’s research design in highlight. (Saunders et al., 2016) The researcher will take the role of a participant-observer, doing what could be described as consulting, while simultaneously taking the role of a project coordinator. About the researcher’s point of view, and on the nature of observation as a data-gathering technique, more will be said in Chapter 3. 1.4 Thesis structure The present work includes a total of seven chapters. The introductory nature of this first one is followed by a second chapter of literature review on project management, innovation and innovation projects. The project management review encompasses not only traditional and agile frameworks but also some hybrid configurations. In the second chapter still, the criteria for the characterization of innovation projects are shown according to some authors. Approaches to the management of innovation projects are also explored. A third chapter lays out the research methodology used throughout the study, placing the considerations and strategy that determined the course of the investigation. Chapter four goes through the detail of the research context. It presents the company where it unfolds, identifies the PM practices found there, and synthesizes the issues surfacing from the experienced project environment. 5 Chapter five includes results from the research, presenting observational and statistically gathered data, reflections and action drivers for its development. Artifacts produced within the research’s domain are shown here too, and elsewhere, at the Appendix section. The sixth chapter discusses the findings and results of the research. The seventh and final chapter concludes this thesis, hinting at additional project improvements and possible lines of future research. 6 2. LITERATURE REVIEW This chapter covers the state-of-the-art on project management and innovation projects. The first subchapter introduces the emergence of PM and gives an overview of some common frameworks on the field. It would be impractical to cover in detail all available frameworks, so a selection based on relevance to this work was made from classical PM, Agile PM (AgPM) and hybrid approaches. The second subchapter describes the types and characteristics of innovation projects. Examples of tools and practices to manage innovative enterprises are also covered here. A chapter’s summary is given at the end. 2.1 Project management Project management is a social construct. Martin Barnes, ex-president of the Association for Project Management (APM), affirmed that “at its most fundamental, project management is about people getting things done” (APM, 2020). People get things done everywhere, all the time, as they go about their lives. They have been doing it for so long that it could be said, projects have been managed since immemorial times. Through generations of life goals and personal objectives, human society owes uncountable achievements to that entrepreneurial spirit. It was not until recently, however, that the language of contemporary PM started to take shape (Morris, Pinto, & Söderlund, 2011). The inception of the field can be traced to the 1950s, to the Program Evaluation and Review Technique (PERT), which is credited for the fruition of the US Navy’s Polaris Project (Engwall, 2012). Around the same time, also in the U.S.A., what would be known as the Critical Path Method (CPM) was being tried at DuPont, a company involved in the Manhattan Project. Both these projects would be determinant to the success of the American Second World War effort, thus placing PERT and CPM in the industry and business spotlight. In broad terms, while PERT focuses on monitoring work progress, the CPM highlights project planning, scheduling and cost control (Kelley, 1961). As Tereso et al. (2019) explain, this kind of rationalistic approach rests on the assumption that in managing projects “(…) there are identifiable patterns and generalizations, from which rules, controls, and guidelines for “best practices” can be established (…)”. Through such practices, the settling of PM as a research and professional field has happened since then, aided by the foundation of standards and reference institutions across the globe. Products of the growing PM body of knowledge include A Guide to the Project Management Body of Knowledge (PMBOK® Guide) authored by the Project Management Institute (PMI); the Individual Competence Baseline (ICB4) from the International Project Management Association (IPMA); the APM 7 Body of Knowledge (APM BoK) published by the Association for Project Management (APM); among others. According to the APM BoK, project management is “(…) the application of processes, methods, skills, knowledge and experience to achieve specific project objectives (…)”(APM, 2012). The PMBOK, in its turn, defines a project as “a temporary endeavor undertaken to create a unique product, service, or result” (PMI, 2017a, p. 4). In short, project management is a combination of organizational processes and resources (cost), that are bound in time to deliver tangible or intangible value (scope), under predetermined requisites (quality). The relationship between these variables has been condensed in the classical iron-triangle of PM (Figure 2) which, to this day, remains fundamental to how people perceive project success (Pollack, Helm, & Adler, 2018). Figure 2 - The PM iron-triangle (triple constraint). Adapted from Atkinson (1999) . Almost everyone understands how delays and cost overruns impact project performance – time and money are universally valued – hence their importance to what (good) management is supposed to be. But quality seems something harder to grasp. Representations of the iron-triangle may even use quality and scope interchangeably. Duarte et al. (2019) argue that to deal with numerous different projects, Project Management Offices (PMO) tend to simplify controls to the management of cost, time and scope, which do not accurately reflect all project dimensions, such as organizational strategy or stakeholder interests. For many decades now, balancing the triple constraint has proved insufficient to secure project success (Atkinson, 1999; Pollack et al., 2018). Such limitation is even seen as the precursor to the Agile Manifesto movement, as will be further explained. PMBOK’s 5th edition suggested that to the initial triangle 8 constraints, project resources and risks were added (Figure 3). It adverts “(…) if any one factor changes, at least one other factor is likely to be affected”(PMI, 2013, p. 5). Figure 3 - The PM star, with Quality, Resources and Risks adding to the classical iron-triangle. Author’s elaboration based on PMBOK 5th ed. (PMI, 2013) . One aspect over which PM standards, researchers and practitioners agree is that there are no universal success factors, and likewise, no universal PM frameworks that apply to every project reality (Shenhar, Tishler, Dvir, Lipovetsky, & Lechler, 2002). 2.1.1 Agile project management Agile is not so much a methodology, but rather a mindset that started to emerge among IT developers back in the 1970s (Larman & Basili, 2003). Already back then, even if projects were to finish within time and budget, the output of 2-3-year-old requisites could very well be outdated in quickly changing business environments (Collyer, Warren, Hemsley, & Stevens, 2010; Collyer & Warren, 2009). Although waterfall approaches (see subchapter 2.1.2) had brought a sense of structure to software development, there was growing discontent with application delivery lag. Thus came to be the Manifesto for Agile Software Development (Beck et al., 2001) with its four core values (Figure 4). 9 Figure 4 - The four core values of the Agile Manifesto (PMI, 2017b, p. 8) . Its authors advocate New Product Development (NPD) need for more speed and flexibility, highlighting people’s over process perspective, fitness for purpose, proximity to the customer, and reaction to everchanging project requisites and conditions. Agile approaches to project management have increased in popularity since. According to the State of Agile™, a survey of the global software development community with over one million respondents, 97% of the surveyed companies were practicing agile development methods as of 2018 (VersionOne, 2018). The previous year, with over three million PM respondents across industries worldwide, PMI’s Pulse of the Profession® survey revealed that 71% of organizations were using agile “sometimes or more frequently than in the past” (PMI, 2017c, p. 10). Agile comprises several team-level frameworks, e.g. Scrum, Kanban, Dynamic Systems Development Method (DSDM), Extreme Programming (XP). Scrum practices are still referred to as the most popular and extensively used (Hobbs & Petit, 2017; VersionOne, 2018). For large cross-functional team or enterprise-level projects, agile scalability might be achieved through practices such as the Disciplined agile Delivery, DaD, Large Scale Scrum, LeSS, the Scaled Agile Framework, SAFe, or Scrum of Scrums, SoS. Most of these scaled frameworks use Scrum at the team-level (Diebold, Schmitt, & Theobald, 2018). Agile is known for being flexible, adopting ‘just enough’ planning at the design front end. Its frameworks are based on a series of timeboxes that gradually deliver business value, in close involvement with customer’s changing needs. Project details and decisions are deferred in time, since change to the scope is seen as a natural and inevitable occurrence during the development cycle (Choudhury, 2019). 10 Scrum Scrum is the most widespread agile framework on the field, being described as a set of values, principles and practices that enhance the aspects of fast feedback, continuous improvement, quick reaction to change and swift project delivery (Scrum Alliance, 2020). Releasing early and often has a positive effect on the return of investment compared to traditional projects, where all the work is released in full at the end. This allows for adjustment to customer, sponsor or end-user feedback, enhancing project value within a lean mindset. This strength can become a liability if no meaningful client involvement is secured throughout the project lifespan (Wysocki, 2019). Most importantly, Scrum is not a linear, standardized process to methodically follow, but a framework for organizing and managing work (Rubin, 2012, p. 13). Schwaber & Sutherland (2017), who were among the Manifesto signatories, identify transparency, inspection and adaption as the three pillars over which Scrum stands. Transparency means there is an explicit and shared understanding of the process, its aspects and responsibilities, assisted by rules, roles, and a common language for its participants. Scrum participants should be keen observers of the produced artifacts to detect issues early on. This way, inspection allows for adaption, and adaption means if the process outputs surpass the established limits, corrective actions will keep the project scope in check. Inspection and adaption are formally exerted during scrum events, also known as ceremonies. Together with roles, artifacts and rules they compose the Scrum practices summarized in Figure 5. Figure 5 - Scrum practices. Adapted from Rubin (2012, p. 14) 17 Essential SAFe serves as the framework foundation, by merging team and program level in an organizational structure called the Agile Release Train (ART). The ART is a long-lived team of Agile teams and key internal stakeholders, which include e.g. Product Management and Business Owners (see bottom left field on Figure 9). The train sustainably delivers the features and technical infrastructure that makeup business value. Agile teams use Scrum, Kanban and XP (Extreme Programming – another agile method) techniques to build these functioning solutions and enablers. They do so every two weeks, through tested system-level increments, known as System Demos. After four of these, a Program Increment Planning Event (PIPE) is held (thick yellow columns on Figure 9). The ART alignment and coordination is secured through these large-scale, face-to-face meetings. A number of agents help with ART adaptation by synchronizing the teams (Table 2). Table 2 - Essential SAFe roles. (Knaster & Leffingwell, 2019) Role Description Product Management Represents the voice of the customer (VOC). Works with PO, which, in their turn, translates customer needs to the Agile Teams. Defines and prioritizes features and enablers on the PI backlog and establishes validation criteria (DoD). Release Train Engineer (RTE) Acts as chief Scrum Master for the ART. A servant leader that enables the flow of value e.g. through the program Kanban and by facilitating PI planning and Inspect & Adapt events. System Architect/Engineer A single person or a small cross-disciplinary team that defines the whole system architecture. Identifies non-functional requirements, plus the critical aspects and interfaces for its subsystems. Because the ART is made of several Agile teams working on a single value stream, there is only so much complexity it can carry. Large solution SAFe configuration combines multiple value streams into the socalled solution train. It is another critical organizational structure that leads several ARTs and external suppliers towards a common solution vision, mission and backlog. This scalability level is concerned with a solution intent, a repository for present and future solution options, that supports system definition, its communication, verification and validation. Solution intent is expressed in set-based, option-enabling designs and cross-domain information systems. It also backs compliance and contractual obligations (Scaled Agile Inc., 2019c). At this level, the following roles are defined: 18 Table 3 - Large solution SAFe roles. (Knaster & Leffingwell, 2019) Role Description Solution Management The VOC liaison. Responsible for the solution vision, backlog and roadmap, as well its requirements (features and enablers). Guides the work through the solution Kanban. Solution Train Engineer (STE) As does the RTE at the Essential level, the STE is a servant leader that coaches and value-drives the work of ARTs and suppliers alike. Solution Architect/Engineer A person or small team responsible for defining the technical and architectural vision of the solution at hand. At the portfolio level, SAFe aligns strategy with execution by organizing solution development over one or multiple value streams. Portfolio SAFe has the highest level of decision-making and financial accountability. I.e. through budgeting and governance mechanisms, it ensures value streams are directed to the right products and solutions development, thus achieving the company’s ultimate business objectives (Knaster & Leffingwell, 2019; Scaled Agile Inc., 2019b). To summarize, portfolio SAFe is meant to guide the company in its mission, setting and governing the core strategic decisions that create value. Essential SAFe implements that mission, through synchronization and support of the multiple agile teams working at one or more moving solutions. This team-ground level within essential SAFe is the lowest in the framework. For large, complex systems development, there is the optative, intermediate large solution SAFe (Kalenda, Hyna, & Rossi, 2018). Research findings on the success of agile scalability, hereby SAFe, at higher organizational levels, have yielded scant results (Dikert, Paasivaara, & Lassenius, 2016). Effective customer collaboration, greater project visibility and better communication, coordination and control were found to be driving success factors (Shameem, Kumar, Chandra, & Khan, 2018). Kaufmann, Kock and Gemünden (2020) mention that, in practice, companies have agile portfolio approaches following a combination of frameworks or a self-developed one. Regardless, their study suggests agile capabilities positively impact portfolio success, through emerging strategy recognition across organizational structures. Of course, implementation success factors can become serious handicaps if poorly managed. A recurring challenge companies face on framework rollout is resistance to change (Kalenda et al., 2018; Putta, Paasivaara, & Lassenius, 2018). On this regard, some Manifesto signatories have been generally disapproving of scaling Agile and even openly critical of SAFe® (Hohl et al., 2018). They believe that, despite its intent, it overburdens people with a plethora of new roles, processes, artifacts, etc., and will, in fact, undermine the core values 19 of the Agile Manifesto (Figure 4). This echoes some organizations’ perception that SAFe drove them “away from agile” (Putta et al., 2018). Without actual reform of practices and mindset, scaled Agile may be a mere guise of the same bureaucratic, imposed management process of traditional frameworks (Denning, 2015). Such findings highlight the importance of tailoring any PM framework instead of forcing it upon the organization. Communication processes (top-down and bottom-up) also have an important part to play in defining the appropriate configuration to achieve the best strategic, innovative, business potential. 2.1.2 Classic project management and PMLC Traditional PM is the bedrock of contemporary project management. However, at the turn of the XX century and after decades of consolidation, the reliability of classic PM frameworks was starting to dwindle (Koskela & Howell, 2008). The simultaneous rise of Agile explains why, still today, classic and Agile methods are pitted against each other. Context is important to understand the merits and limitations of each, linked, as they are, to the kind of Project Management Life Cycle (PMLC) they propose to implement. The modern conceptualization of PMLC assumes all projects evolve through a sequence of steps or stages. This started with the representation of networks of project activities, such as PERT, CPM diagrams, Gantt charts and Work Breakdown Structures (WBS) (Maylor, 2001). Figure 10 - The project management lifecycle stages. (Dawson, 2007) The project is regarded as a process through which system inputs (e.g. budget, resources, requirements) are transformed into outputs (e.g. new products, new processes, other benefits). Traditional PM follows a predictive approach, where project stages, or phases, succeed each other linearly (Figure 10). Dawson (2007) makes a point on how, historically, the PMLC and the product development cycle have been entwined, despite being different things. Royce (1987) described a systematized, product development cycle that became known as the waterfall method. Waterfall was then the paradigm of software development, with project status “cascading” from one project phase into another (Figure 11). 20 Figure 11 - The waterfall model - implementing steps to large computer program delivery. (Royce, 1987) Around the same time, Cooper (1990) made a similar analogy between managing product innovation and a physical production process. He reasoned that, to improve process quality, variance must be removed. According to the Stage-Gate (SG) rationale, project phases are like workstations and, in-between them, quality checkpoints exist to assess output conformity. Only by meeting predetermined criteria at these gates, can the project move on to the next level (Figure 12). In SG models, the call at the gate to either proceed, terminate or put the project on hold belongs to the sponsor and top management. Figure 12 - Overview of a Stage-Gate system. (Cooper, 1990) 21 The current PMBOK process-based approach still preserves some likeness to the SG system model. It divides the PMLC into five generic stages or process groups: initiating, planning, executing, monitoring & controlling, closing (Annex 1). About the predictive PMLC it says that it is “characterized by an emphasis on specification of requirements and detailed planning during the beginning phases of a project ” . Each project phase includes a logically related set of activities that lead to the completion of at least one end deliverable (PMI, 2017a, p. 666) . As an ever-evolving body of knowledge though, the PMBOK came to acknowledge that not all projects can be planned beforehand. Its latest edition already mentions AgPM and hybrid management methods. The appropriate PMLC can be traditional (predictive), Agile or an intermediate solution (Figure 13). Figure 13 - Project management lifecycles. (PMI, 2017a, p. 666) By following a linear PMLC, classic methodologies are a good fit for carry-over projects or those of a kind that has been repeated multiple times, like construction and installation enterprises (Wysocki, 2019). It is not uncommon for companies or divisions to have one standard product development process, and one PMLC to see it through. It could be, however, that different phases of the same project require different PMLC approaches (PMI, 2017a). Furthermore, adherence to a PMLC depends on the organization's project management maturity level. Recounts from Pennypacker and Grant (2003) and Mullaly (2006) showed a majority of companies operate in environments where PM processes exist but are not an organizational standard. I.e. they are structured but not institutionalized. Management might support the implementation of PM but there is a lack of consistent understanding and involvement with the practice. Functional Managers (FM) gravitate towards the larger, more visible projects that get 22 executed in a systematic way (Pennypacker & Grant, 2003). Wysocki (2019, p. 405) stipulates these low maturity level organizations apply PM methodologies that range from informal, ad hoc management to a “carefully crafted and monitored adaption of a commercial model”. In practice, if not in theory too, these solutions could be considered hybrid PM approaches. 2.1.3 Hybrid project management What hybrid PM is, is not consensually defined in the literature, but it can be argued that it reflects the need for a tailored PM solution, capable of answering each project’s unique environment. For instance, Ali, Tirumala and Babu (2016) have worked on a hybrid agile model that merges Scrum and Feature Driven Development (another agile method). They have done so hoping to arrive at a solution that overcomes each framework's individual limitations, which is common ground for all hybrid PM attempts. Karlström and Runeson (2005) provide an early and often cited reference of combined use of Agile and classical frameworks. Their case study review of software development projects in large companies describes how Stage-Gate contexts are accommodated for XP (Extreme Programming) teams. Besides the expectable resistance that comes with the introduction of the reform, Agile showed to benefit microplanning and daily work management. It also significantly improved communication, with face-toface meetings and functioning products yielding better results than written documentation. Cooper (2016) himself has been acknowledging similar gains over the past decade, from embedding AgPM within the stages of the SG model. Baird and Riggins (2012) chose instead to nest a classic planning phase within AgPM (Figure 14). Figure 14 - Applied project process, schedule and deliverables. Adapted from Baird & Riggins (2012) The authors found traditional project planning worked well as a catalyst for Agile sprints. Even though it did nothing to reduce project uncertainty or its duration, it provided a well-thought-out kick-off. From a strategic standpoint, they held up the Agile core value of prioritizing working solutions, over extensive documentation, thus instructing the teams to focus the second sprint on “the tasks representing the core, 23 essential components” of the project. By delivering a Minimum Viable Product (MVP), as early as possible, they removed the critical development aspects out of the way for the final sprint. The hybrid PM approaches mentioned this far either embed or alternate classic and Agile PMLC, at specific abstraction levels or time-periods. This is in line with Wysocki (2019) and the PMBOK (PMI, 2017a) which recommend the selection of different, befitting PMLC to distinct phases of a project. Alternatively, other sources have proposed hybrid solutions by thoroughly mixing traditional and Agile approaches into a single framework. Traditional PM is usually the starting point for organizations looking to improve their PM processes and SG hybrids are a kind of common approach (Sommer, Hedegaard, Popovska, & Jensen, 2015). For instance, Conforto and Amaral (2016) propose an iterative development approach guided through a phase-based process. Their Iterative and Visual Management Method (IVMM) is stratified into 3 levels, each having a visual whiteboard to promote visibility of project status and performance. The upper level is a SG system, with phases, milestones and macro-deliverables, i.e. the high-level planning. Iteration belongs in the intermediate and lower levels. The authors go to describe how the intermediate level is where the team breaks down and prioritizes the deliverables to develop in each project phase. The lower level is kept for weekly activity planning. These are very much like Scrum practices, especially considering the visual whiteboards (Kanban boards) that aid in the process. Even if without a reference to Product Owner or Scrum Master, the intermediate and lower levels correspond, in fact, to product backlog grooming and sprint backlog. Another Agile/Stage-Gate hybrid proposal by Sommer et al. (2015) similarly divides the NPD framework into 3 levels. Figure 15 - Agile/Stage-Gate hybrid framework for NPD. (Sommer et al., 2015) 24 The higher-level concerns strategic project management and preserves the phases and gates of the SG model. It is overseen by product portfolio management and a steering committee. The intermediate level concerns the value-chain/project portfolio coordination. It is managed by stakeholders from across the organization, who periodically meet around a physical board to coordinate resources. The lower level of project execution concerns the development team, is aided by a PM and applies Scrum methods. What both IVMM and Industrial Scrum (Figure 15) frameworks do is to preserve the SG system at a high organizational level, while using Scrum or other Agile framework at the lowest levels. Schuh et al. (2018), writing on an Agile-Waterfall hybrid, systematized this in a model over which, project high and low abstraction levels interact with the dimensions of structure and process (Figure 16). Figure 16 - Hybrid project design defining features. Adapted from Schuh et al. (2018) This hybrid PM solution has both traditional and AgPM running parallel through the project life cycle. The overall project organization and long-term commitments belong to the macro perspective layer, which follows SG systems. The micro perspective concerns the emerging, short-term facets of the project that are managed at the team level through AgPM. The structural dimension contains the more fixed elements of architecture, design and work organization features. Process concerns time-related aspects (Schuh et al., 2018). Project architecture (A) should be modular to mitigate change propagation across integrated product scopes. Adapting AgPM beyond software development emphasizes the need for cross-functional teams (B). Even if Scrum roles are not fully adopted, a Product Owner team made up of area specialists should be established. The project plan (C) is long-term but Agile teams can iterate their development cycle several times in between phase gates. Some iterations may even stretch across gates, so long as the teams remain focused on delivering an MVP for assessment. To be self-manageable, the Agile team 25 level requires fully dedicated personnel (Conforto & Amaral, 2016; Schuh et al., 2018). Although Agile values working solutions, documentation shall not be forfeited (Karlström & Runeson, 2005; Schuh et al., 2018). Not only is it essential for operational management, but it also supports project synchronization (D). Synchronization, in its turn, is the centerpiece of this hybrid PM model. As such, Agile practices, such as daily stand-ups and large, face-to-face stakeholder assemblies, should be held regularly (Karlström & Runeson, 2005; Schuh et al., 2018). According to Sommer et al. (2015) the mechanisms that drive the benefits of this hybrid PM model have much left to uncover. There is no quantitative data attesting the parallel use of AgPM in traditional PM based organizations (Schuh et al., 2018). Cooper (2016), who conceived the first SG system nearly thirty years ago, summarizes its most common qualitative impacts: increased process visibility, improved team ownership and motivation, and overall better project communications. 2.2 Innovation projects Semantically, innovation is associated with novelty: a new idea, a new method, the creation or reinvention of both what is palpable and intangible. Authors such as Lepak, Smith and Taylor (2007) tie knowledge creation and innovation to organizations’ ability to create value. Furthermore, the definition of innovation’s value in university-industry collaborations and other cross-institutional settings is blurred by multiple innovation sources and recipients. Even so, Chesbrough, Lettl and Ritter (2018) reason that maintaining these symbiotic relationships between institutions is only possible if there is value to be gained for everyone, either during the collaboration’s term or later in time. This means that even when such prospect is not formally recognized (Lee, 2000), organizations engagement with innovation may be driven by the management of its perceived benefits (De Fuentes & Dutrénit, 2012; Fernandes & O’Sullivan, 2021). 2.2.1 Innovation typology In some academic writings, the precept for innovation can be said business or value-driven. Writing on Schumpeter’s theory for innovation, Hagedoorn (1996) described innovation as the successful introduction of new products and processes. Around the same time, the distinction between sustaining and disruptive innovation was penned by Christensen (1995). Christensen’s perspective rests on the assumption that innovation can be a continuous improvement, based or adding on answers to established consumer needs. Or it can be a breaking force that displaces previously existing solutions, claiming their market share and in extremis , rendering them completely obsolete. The premise here is that disruptive innovation challenges the present value propositions/Business Models (BM) on the market, even if it is a 26 by-product of imitation (imitative, copy-cat or me-too innovation) that does not represent a technological breakthrough (Edwards-Schachter, 2018). According to Christensen’s model, disruptiveness is a measure of market impact rather than a sign of inherent technological prowess. In Schumpeterian theory, innovation is tied to the concept of creative destruction and the pace of economic and business cycles. Therefore, in reshaping and ensuring the competitiveness of BM, innovation lies in the key-factors that define a company’s value function. Not only it resides in patented technology or protectable intellectual property, but also in the organizational structures and arrangements that often prove harder to replicate (Teece, 2010). Many terms are attributable to innovation as its typology changes across time and literature. It can be defined as a dichotomy (sustaining vs. disruptive, incremental vs. radical, product vs process, open vs. closed) or through standalone epithets (BM, imitative, frugal, social, radical, reverse, value, etc.) (Edwards-Schachter, 2018; Klarin, 2019). Another possible way to look at innovation is problem-centric. Innovation is essentially about addressing new challenges, finding answers to a certain problem. And the same can be said of the purpose of innovation projects. In this light, defining innovation becomes the definition of the problem at hand. In the June 2017 edition of Harvard Business Review, Satell (2017) presents us with four types of innovation (Figure 17): sustaining, breakthrough, disruptive and basic research. Figure 17 - Types of Innovation. (Satell, 2017) Considering the elusiveness of its boundaries, it might be difficult to frame the developing LiDAR technology for automotive application inside a single domain. Nonetheless, it would be safe to say that SC, an academic-business partnership, was primarily designed to expand LiDAR state of the art and 33 degree of uncertainty each innovation project has, lies not in just one technique, but in a combination of many. Design thinking, systems thinking, concurrent engineering and other research fields do not rule out traditional PM, but rather look for the better balance between these and more flexible instruments (Kapsali, 2011). Detail on the some relevant IMT follows. Figure 20 - Innovation management methodologies and tools. Adapted from (Hidalgo & Albors, 2008) Planning and controlling There are two predominant approaches to planning, rooting back to the rational and adaptive schools of thought. According to Mintzberg (1987) “(…) strategies can form as well as be formulated”, i.e. planning for a project can be an explicit, deliberate effort or have an implicit, emergent approach. The rational take on planning is an act of prediction. Generally, it comprises a linear sequence of activities, including the project main path (baseline), and some contingent detours that accommodate for the possibility of setbacks. Classical PM references, such as the PMBOK® and PRINCE® (Projects in Controlled Environments), are corollary to such an established practice of structured, prescriptive planning. Even if readily associated with time (schedule) constraints, formal planning processes may apply to all project knowledge areas (see Annex 1). Under such logic, project execution is preceded by a 34 planning phase. In traditional PM, the project plan is typically elaborated from the Project Charter (PC). Therefore, the level of definition of the charter will be reflected on the level of detail of the plan. Such detail will include the project purpose, overview, schedule, stakeholders, resources, risk and evaluation methods (Meredith et al., 2017). If both project uncertainty and complexity are low, classical planning with integrated risk management should equate to high project performance, as opposed to project learning and selection during execution, which are more expensive approaches (Loch, Solt, & Bailey, 2008). For highly explorative innovation projects, planning has limited applicability however, because of the absence of traditional elements to it, like a schedule, feasible task breakdown (WBS) and clear, concrete objectives (Lenfle, 2008). Furthermore, innovation is a complex learning process that often needs to repeat past tasks, because of interdependencies. New findings might change the worth of the already executed portion, and their frequency can make of constant re-planning a burdensome effort. Whereas classical PM actively resists such change, to enable the application of formal process controls, AgPM iterative development expects and embraces it (Meredith et al., 2017). PM standards, such as the PMBOK®, have now updated to include agile frameworks, recognizing the need for such adaptability during project execution. In between classical PM and formal AgPM frameworks, some intermediate solutions have emerged since. Collyer et al. (2010) summarize a few planning styles in dynamic project environments: • “Environmental manipulation” – traditional methodologies, like waterfall detailed planning, where change to project environment and scope is suppressed to better control execution. • “Emergent planning” – also known as rolling wave, iterative or progressive planning. The plan is a sketch or temporary grid over which experimental work is laid on (Lenfle, 2008). AgPM frameworks belong in this type of planning, with feedback or learning loops at its core; also associated with prototyping. • “Staged releases” – the smallest possible scope is released early on. It is associated with the Minimum Viable Product (MVP) concept for lean start-up enterprises (Hart, 2012). The least expensive pilots are released to market to collect quick feedback for further versioning. Not to be confused with release planning, which is belongs with formal AgPM frameworks. • “Competing experiments” – simply put, the strategy of launching several investigation routes simultaneously, to rapidly pin down the optimal or most promising one. 35 • “Alternate controls” – whereas classical PM focuses on the in-between process control, this approach focuses on the involving inputs and outputs, like team selection, clear goals and reward (Collyer & Warren, 2009). The importance of alternate, informal controls counterbalances project reliance in traditional ones. Some research has shown that initiating projects are more dependent on formal process control and may gradually shift towards more serviceable configurations (Heales, Susilo, & Rohde, 2007). This appliance of IMT parallels the previously discussed effects of hierarchy on the project’s outcome. I.e. organic (informal) and mechanistic (formal) control forms seem to have complementary effects and contribute to enhanced innovation performance (Ylinen & Gullkvist, 2014). Barbosa et al. (2020) configurations for high achieving, open innovation R&D projects include a planning approach combined either with partner integration or open and continuous communication. Less formal control is not always the answer, however. For instance, at higher organizational levels, a Stage-Gate systems approach proves effective for managing NPD contexts, even if traditional PM at project level starts to lose its efficiency as the degree of innovativeness increases (Schultz, Salomo, De Brentani, & Kleinschmidt, 2013). Brainstorming Brainstorming is an individual or group ideation process that gained popularity as a problem-solving technique. The term was first penned in the 1950s, on Alex Osborn’s seminal work Applied Imagination . Osborn (1953) originally defined four working principles or rules to conduct brainstorming sessions. Since then, brainstorming and its rules have been tried, expanded and contested in several research fields, mainly those of Psychology and Management (Litchfield, 2008). The original four principles come as follows: • (a) Criticism is ruled out – judgement must be deferred. The purpose of brainstorming is to generate, not evaluate, as many ideas as possible. • (b) “Free-wheeling” is welcomed – even the wildest ideas should be voiced. Today, this is known as thinking outside the box. • (c) Quantity is wanted – the chance of a useful idea increases with the number of ideas; the more, the better. • (d) Combination and improvement are sought – participants might suggest improvement on previously shared ideas, or that two or more ideas are combined into a single prospect. 36 While the first three points promote quantity and flexibility of ideas, the fourth is meant to enhance conceptual combination. One challenge organizations face when resorting to brainstorming is the ability to define expectations for idea generation (Kalargiros & Manning, 2015). It is to say, brainstorming does seek to be a creative process, but goals must be set to keep it a bound effort. The facilitator, a role that may befall the PMg, is the one ensuring brainstorming remains focused. Research has shown, the preceding expectation that managers have will influence the creativity output of project teams. Management initiation, support and recognition of creative effort will yield better results (Tierney & Farmer, 2004). But even if teams dispose of rules and a referee, one cannot but wonder, looking at Osborn’s rules: how can we combine and improve ideas without judging? Would it not be violating one of the other premises? The truth is that brainstorming as a tool for innovative enterprises faced tight scrutiny from the beginning. Since Osborn’s first work, a number of authors consistently proved that idea generation of single individuals outperformed, both in quantity and quality, the output of brainstorming groups (Furnham, 2000; Lamm & Trommsdorff, 1973). Kalargiros and Manning (2015) reason these comparative studies mostly happened in the absence of facilitators. For this, they point to research also supporting that groups can match or surpass the combined output of individuals working in isolation, when trained facilitators guide those groups. Such findings hint at underlying trade-offs that come with each rule or expectation given to brainstorming participants. Litchfield (2008) explains these phenomena derive from the different interpretations each individual has of brainstorming rules. These rules function as temporary project goals. He argues that even if brainstorming's main goal is idea creation, “other goals may be inadvertently activated ” in the process. For instance, the goal set to increase the quantity of ideas (c) might trigger competition for the greater number of contributions between participants. Leaving criticism out (a) is no easy feat either, as some people do not try to, nor do they believe others can refrain from judging. Judging may then turn brainstorming sessions into status auctions, by putting participant reputation at stake. While some personalities thrive with such exposure, others might shy away from sharing their knowledge. Furthermore, combining ideas (d) manifestly requires cognitive processing of others’ ideas, and individuals might abandon their own line of thought to participate in someone else’s. Given such dynamics, it is fairly evident how the summed-up ideas of individuals could surpass the work of a group, or when a facilitator could intervene to keep the latter in check. Brainstorming popularity comes from its early years and lingers to this day. However, group brainstorming keeps being mistaken by a complete problem-solving process (Trott, Hartmann, Van Der Duin, Scholten, & Ortt, 2015). What often happens is that the phases of idea generation, refinement and evaluation are 37 confounded into a single brainstorming event or, worse yet, into a single task (Kalargiros & Manning, 2015; Litchfield, 2008). Such eagerness to get results undermines this IMT usefulness. To address it, both Osborn and other authors built over the original four principles, by incorporating lessons from years of application. One of such attempts was authored by Rossiter and Lilien (1994), who redefined brainstorming principles as: • (i) Brainstorming instructions are essential – should emphasize quantity, not quality. • (ii) A specific, difficult target should be set – make it a bound effort, set expectations, clear goals. • (iii) Individuals, not groups, should generate the initial ideas – individual thought and idea uniqueness benefit from reclusiveness. • (iv) Use group interaction to amalgamate and refine ideas – judgment previously deferred should now be applied, making use of the teams’ complementary knowledge; ideas should be anonymized by the facilitator/manager. • (v) Select final ideas by individual votes – each participant weights in its own anonymous vote; enhances individual buy-in and team commitment to the arrived solution; management should not pass judgment on ideas. • (vi) The time required should be kept remarkably short – brainstorming sessions do not have to be cumbersome and take up whole mornings or days e.g.; lack of structure and meeting preparation often requires follow-up sessions, with loss of focus and morale. Brainstorming has obviously had its share of critics. Group brainstorming might suffer the downside of social inhibition if people do not contribute to avoid criticism (Lamm & Trommsdorff, 1973). There could be production blocking when waiting times make people forget the idea they had before they could speak; or social loafing could mean teamwork might be covering for underperforming individuals (Furnham, 2000). Given its potential inefficiency as an idea generation tool, it remains remarkably popular in most business sectors. That can be explained by the enthusiasm and broader participation the technique instills. In brainstorming sessions, people come together as thinkers, with roles and hierarchy falling to the second plan. It increases decision acceptance and develops team spirit (Furnham, 2000), in part because it also gets credit for the subsequent phases of idea evaluation and refinement. It could be said that, in the end, its biggest accomplishment, especially for innovation projects, is the convergence around a team solution everyone sees as their own (Seeber, de Vreede, Maier, & Weber, 2017). 38 Prototyping Prototypes have long been used in the context of product development. Physical prototypes are traditionally used to assess new products along the dimensions of form, fit or function. The degree of realness put into a prototype, its fidelity, will dictate the ability to reproduce the desired behavior. A physical prototype gives a preliminary experience of look and feel to the user. A great advantage is that it may reveal unknown phenomena, which had been concealed in earlier stages of concept ideation (Toche, Fortin, Pellerin, & McSorley, 2017). There are also virtual prototypes. These evolved from early computer assisted design and modeling tools that primarily provided concept visualization. Today, digital models allow not only 3D representation, but the simulation of the whole system environment, potentially, at a fraction of the cost of physical samples (Wang, 2002). Functional virtual prototypes may suffer still from major limitations, if no available technology can simulate complex component behavior and interaction, under variable working conditions (Toche et al., 2017). Therefore, virtual and physical models are expected to have complementary roles in NPD. Prototyping strategies will have to consider many variables, such as time, cost, size, materials, reliability, level of detail, etc. The ideal solution will be one that can provide the best possible quality, with the lowest cost, at the shortest time (Zorriassatine, Wykes, Parkin, & Gindy, 2003). These are, not coincidentally, the same classical constraints of PM practice. Organizations can be differentiated not only by how they handle projects, but also by how they manage prototypes. Schrage (1996) distinguishes two types of innovation culture in companies. Some are specification-driven, others are prototype-driven. Big enterprises, that need to coordinate great volumes of information and people, tend to belong in the first category. In such environments, prototypes are developed to meet certain requirements, and improvements to performance result from a gradual refinement process. Besides the objective of design refinement, Camburn et al. (2017) explain that prototypes may serve the additional purposes of communication, exploration and active learning. Prototypes as communication vehicles are a particularly intricate subject, because they can be used as persuasion tools in front of project sponsors, or act like artifacts around which team discussion happens (Bogers & Horst, 2014; Schrage, 1996). It can be argued that a specification-driven mindset will regard prototyping just as another IMT, a means to an end – i.e. conformity with requirements. A prototypedriven mentality, however, will value the knowledge-gaining process that comes with trying, failing and trying again. Prototyping has an end in itself – continuous improvement. Prototyping can be a source of project convergence or divergence, something the literature treats as the level of design fixation. Physical prototypes may not cause fixation per se , but the sunk cost effect that 39 comes with prototyping activities was found to do so (Viswanathan & Linsey, 2011). The prototyping speed that available manufacturing technologies allow will influence design fixation too (Camburn et al., 2017). This means project teams are more unlike to deviate from a specific solution, on which much time and money have already been invested. Time itself assumes great significance on prototyping competitiveness (Schrage, 1996). Although it appears that the time spent on prototyping does not correlate with improved design outcomes (Häggman, Honda, & Yang, 2013), the timing of prototype building initiation does. There is evidence that starting to prototype early on the project leads to better project results (Häggman et al., 2013; Jang & Schunn, 2012). 2.3 Summary of literature review This chapter’s review allowed to frame present-day PM practice and understand how different types of PLCM may suit each project’s needs. While iterative planning and AgPM frameworks may seem better fits to innovation projects, particularly those showing high levels of uncertainty, it could be that detailed planning and intensive requirement elicitation are a good approach within some project stages. The more recent genesis of hybrid PM results from a widespread tendency to tailor both traditional and AgPM into more serviceable frameworks. This review also allowed to summarize the most distinctive features of AgPM, in an attempt to understand where its flexibility resides. Within its most common solutions, the aspects of project transparency, workflow visualization, adaption and improved communication processes are particularly relevant. Innovation project types, its characteristics and some IMT have also been reviewed. Organizations and PM practitioners alike ought to recognize the importance human resources’ mobility and absorptive capabilities have in knowledge creation and exchange. This becomes ever more relevant as innovative enterprises transition to more cooperative, open innovation settings. Within the organization’s boundaries, hierarchical arrangements and leadership exertion define how innovation might be championed across its ranks. These insights will inform potential action routes for the participant observation phases of this work. They will also be determinant to stakeholder handling within SC.LiDAR’s sphere. Amongst the tools for managing innovation, the processes of planning and controlling were reviewed. Much like between traditional and AgPM, options vary between tight formal controls and freewheeling approaches. The processes for brainstorming and prototyping were also covered due to their importance in birthing unifying ideas. It is around them that successful teams and technical solutions will be developed. 40 3. RESEARCH METHODOLOGY Research methods are, themselves, object of research, with vast knowledge backgrounds to attest both their strengths and inadequacies. In Chapter 1 the research design was laid out, so this chapter will contextualize the chosen research strategy and data collection methods. A succinct overview of their characteristics, advantages and disadvantages will be given, as well as the motive for their selection for the current research purpose. 3.1 Research strategy The chosen approach for this research is that of a case study. According to Saunders et al. (2016), a case study sets out to understand the relation between the research topic and the environment where the research unfolds. This seems appropriate, considering the vast body of knowledge that precedes PM practice and the researcher’s initial unfamiliarity with the real-life setting where it happens. Case study research has a degree of flexibility not found in other qualitative approaches, like phenomenology or grounded theory (Hyett, Kenny, & Dickson-Swift, 2014). This versatility proves useful when the boundary between the studied phenomena and the environment where it occurs is unclear (Saunders et al., 2016). The research question “ What issues affect SC.LiDAR project lines coordination and how to address them? ” implies there is a problem that not only needs identification but early answers too. It is expectable that, from a researcher’s point of view, the researcher and project coordinator functions will start to merge. That is, the frontiers between studied phenomena and environment will become increasingly blurred. Case studies are often criticized as a research approach because they struggle to deliver the generalizable, consistent results that set the foundations for theory building. Saunders et al. (2016) see this as a misunderstanding stemming from the perspective of positivist philosophers. Positivism is synonym to empiricism, and in empiricism, knowledge can only be earned a posteriori , through sensory experience. Case studies such as this, however, can be interpretive, i.e. resort to both intuitive, introspective knowledge, as well as naturally occurring sources of knowledge in the physical space (Hyett et al., 2014). In other words, both researchers’ a priori knowledge and experience, as well as other people’s testimony and interaction, will substantiate the findings of the study. This contextuality may be in the way of generalization and theory building. However, the purpose of a case study is not to describe the world, but to describe the case (Johnson & Stake, 1996). 41 A case study does not strictly adhere to a single paradigm or assumption. It resorts to varied data collection and analysis methods, in order to better comprehend the case, guided by context and emergent data (Hyett et al., 2014; Saunders et al., 2016). Ultimately, this strategy was chosen on the principle that if the PM approach should be tailored to project reality, within reason, the same should happen with the research strategy and applied methods. 3.2 Data collection This research applied a mixed-methods data collection approach. Mixed methods not only allow to be on the lookout for emergent data sources, but they also improve the confidence in the research’s empirical findings. Using multiple methods may provide information that would otherwise not be retrievable through one single method. Besides, having redundant information from different sources can reduce sampling errors; and not relying on one single method can reduce potential bias (Axinn & Pearce, 2006). This research used observation, surveys and document analysis as its primary probing methods. Observation Observation is a widely used data generation method, where the researcher immerses itself in the studied environment. It involves consistently observing, registering, analyzing and interpreting people’s interactions, events and the like (Hox & Boeije, 2004). This research was based on qualitative participant observation. Saunders et al. (2016) distinguish between this and quantitative structured observation. While participant observation is concerned with the action motive, structured observation cares about action frequency. The main advantage of participant observation, especially when compared to other data gathering techniques, derives from the high involvement that it allows. According to the same authors, there are 4 possible ways of positioning observational research (Figure 21). 42 Figure 21 - Types of observational research roles. (Saunders et al., 2016) The main distinctions in observer positioning consist in taking an active or passive stance – upper vs. lower quadrants, on Figure 21 – and being a declared or concealed observer – left vs. right quadrants on the same figure. The chosen approach was that of participant-as-observer. Not only was the researcher admitted as a company employee, which presumes a degree of participation in business processes, but also the research and its purpose were known to project stakeholders from the start. There could be some doubt on whether to take a more active or passive role, were it not for the sense of urgency in finding answers to the research question. By the time this research kicked-off, the project was already past its mid-life. Furthermore, when the researcher was introduced to the project, there was no preceding PMg role to fill in, so intervention in the project course was, in a way, legitimized through the observational role. Participant observation is time-consuming and early interpretations may be erroneous because the researcher must first understand the environment where it operates. Similarly, observer error may affect late observations, as interpretation might drift from early meanings to deeper ones. Another important aspect stems from how the researcher’s known presence or purpose affects the observed sample’s behavior. This is recognized in numerous Psychology and Sociology works as the Hawthorne effect, Pygmalion effect or, as Saunders et al. (2016) called it, the observer effect. In short, these effects account for the possibility that observed individuals will change their behavior either to show improved performance, satisfy the observer’s expectations or, in any other way, try to conscientiously condition the study results (Rosenthal & Jacobson, 1968). This poses an unavoidable threat to overt observation’s validity, which can be countered to some extent. Because a participant-as-observer role was chosen, 49 PL named P00 Coordination was created by Bosch to accommodate for this research (Table 6). Beyond FM’s responsibility level, each PL has a responsible and co-responsible person. Table 6 - SC.LiDAR project line managerial oversight. 4.2 Standards, processes and PM practices in place To speak of PM practices, it is necessary to mention the standards and processes supporting project development at Bosch. The standard for engineering is the Bosch Engineering System (BES) that is ruled by a central directive (CD 04510) of mandatory adoption for every organizational unit of the Group. Its purpose is to raise engineering activity effectiveness and efficiency, through methods and approaches that mitigate the typical threats of the development process. This way, Bosch ensures improved, in-built quality for its products and services. BES contains a set of regulations, which include, work organization (WO) requirements, product engineering (PE) requirements, and engineering product quality (EPQ). Both project level WO and PE requirements apply along the Bosch Innovation Framework (Figure 25)(Robert Bosch S.A., 2020d). Figure 25 - Bosch Innovation Framework. (Robert Bosch S.A., 2020d) Responsible Functional Manager (FM) Project line (PL) ENG3 SC.LiDAR.P12 ENG41 SC.LiDAR.P02 / SC.LiDAR.P03 / SC.LiDAR.P05 SC.LiDAR.P06 / SC.LIDAR.P09 / SC.LiDAR.P11 ENG42 SC.LiDAR.P01 / SC.LiDAR.P04 / SC.LiDAR.P06 SC.LiDAR.P07 / SC.LiDAR.P08 / SC.LiDAR.P10 Researcher SC.LiDAR.P00 50 Being mandatory, the directive anticipates the need of tailoring its requirements either at the business or at project/operational level. At the business level, it shall be done by the business owner (Dep. Head in Figure 24), who in turn, shall have designated people tailoring the requirements at the project/operational level. As such, customization can be done e.g. by an agile coach/master, an RTE or PM-coach for the projects pertaining to an organizational unit such as CC-PS (Robert Bosch S.A., 2020e). From a PM perspective, the most meaningful of these regulations is the work organization (WO), as it addresses organizational and operational structures, as well as the rules and principles of collaboration. The project level WO has a total of 14 requirements, 11 of which concern process. There is 1 requirement of business & architectural concern and 2 of organizational concern. Table 7 - BES work organization requirements. Abridged from (Robert Bosch S.A., 2020e) BES – WO requirements (project level) Description (implementation hints) Business & Architecture 2.1 Project-specific decisions take risks (threats and opportunities) into account. Identify, prioritize and quantify risks systematically and continuously. (…) Derive risk response strategies for threats (avoid, mitigate, transfer, escalate, accept) and opportunities (exploit, enhance, share, escalate, accept). (…) Consider PMI (project management institute) risk management process. Process 2.2 Project or operational management is established. For projects see CD 02500 Project Management at Bosch, Bosch Project Management Handbook. Consider alternative leadership concepts if reasonable, e.g. derived from SAFe. (…) 2.4 Value add is reviewed regularly by relevant stakeholders. Value add should be created in appropriate iterations/loops and reviewed continuously, e.g. by fast provision of prototypes, fast verification of models and assumptions. (…) (…) 2.6 Measures are implemented to control the workload and avoid multitasking. Workload and bad multitasking can be avoided by e.g. using team or Kanban boards, introducing pull principles and limits for work in progress, small work packages with clear acceptance criteria. (…) 51 BES – WO requirements (project level) Description (implementation hints) Process 2.7 Concepts creating transparency are established. (…)Define and implement concepts to ensure availability of the right information at the right time to the right people. Transparency is a basis for e.g. a common understanding, aligning work, avoiding double work. Consider transparency e.g. for communication of project status, comprehensible decisions, availability of relevant information. (…) 2.9 Nominated members are allocated to complete project phases/activities with sufficient capacity. Maximize consistency in resources, i.e. teams stay the same as long as possible. (…) Organization 2.13 All required roles are established. A role contains the description of tasks, capability, responsibilities, authorities and competencies. Roles can be included in e.g. project management plan. 2.14 For teams the level of self-organization and authority to decide is defined. (…) Teams should achieve a maximum of selforganization and authority to decide. (…) Table 7 shows some of the project-level WO requirements. All directive attachments include implementation hints, from which passages were transcribed. These include multiple references to PM standards and frameworks e.g. PMBOK’s risk management process (2.1), iterative PMLC (2.4), lean principles for work management (2.6) as previously described in Chapter 2. Requirement 2.2 mentions another Bosch central directive for PM. The CC-PS division, specifically, has a divisional directive (DD) for PM: CC-DD0301-2 Project Management (Figure 26 – right side). Figure 26 - CD 04510 BES, CD 04510 BES Attachment 1: Work Organization and CC-DD0301-2 Project Management front pages. (Robert Bosch S.A., 2020d, 2020e, 2020c) 52 The divisional directive is quite comprehensive, once more, contemplating the need of tailoring. Among other things, it defines how the division distinguishes its project types, considers risk, change management, and traditional project elements such as the Project Charter (PC) and the project management plan. It describes a phase-based process flow for PM, from initiation to project closure, with all intermediate steps having associated roles, responsibilities, inputs, tools and outputs. It contextualizes the PM role in traditional, hybrid and agile project configurations. It defines the roles of PMg and the project management office. The PMg “(…) is responsible for the entire project (…) has the managerial authority over the employees who have been assigned to him/her within the project”. The PMO “(…) acts as both a competence center of and a ‘home’ for project management (…) Training, coaching, consulting, guiding and controlling for project management are the main PMO commitments”. Looking past company standards, some PM practices were almost readily observable from the start at CC-PS Braga. The division has a two-week onboarding process for new employees. Besides multiple info sessions with business specialists, newcomers, who are gathered into temporary teams, go through a Scrum basics training. It is hoped that, later, this will make for smoother integration in their actual teams. At CC-PS multiple product lines are explored, among which, LiDAR is but one. This research is dedicated to the subset of 12 LiDAR project lines, within the Sensible Car program. At the office, these are generally referred to as the Innovation project. However, LiDAR is also being developed on the Business Plan (BP) side. This distinction was neither transmitted nor immediately apparent to the researcher so, during the first weeks, some attention was paid to how BP operates. BP LiDAR is organized according to the SAFe® framework. The general working principles of this Agile framework have been laid out on Chapter 2. As for LiDAR Innovation (SC.LiDAR), no evidence was found that there was any kind of standard framework in place for its management. More considerations on LiDAR ART will be made at the beginning of the next chapter. 4.3 Diagnosis/problem definition Not much was known about CC-PS Braga at the beginning of this research. The researcher applied to an internship at Bosch, with the premise that there were 12 project teams, or project lines, as they will be mentioned, struggling to coordinate amongst themselves. The researcher was admitted at the end of October 2019. Introduction to project personal happened on the first days of December 2019. During that time, which was partially spent at the onboarding process, 53 the researcher tried to understand how the organization worked, mainly through the scheduled info sessions and by talking to those available around him. The following points summarize the most relevant considerations gathered in that time: • The 12 teams are working to deliver a LiDAR sensor for automotive application, which is considered an innovative feat; • The degree of technological readiness was unknown to the researcher; • The project team was potentially large, but exactly how many and who these people were was unknown; • The ability of the 12 teams to function as a single team was unknown; • The scope of SC.LiDAR and how it relates with each individual project line was unknown; • It was not clear if the project was following a defined PM methodology. After an initial observation period, the research question “What issues affect SC.LiDAR project lines coordination and how to address them?” was further elaborated into three objectives: • Help SC.LiDAR teams to identify, define and agree on final deliverable(s) requirements; • Improve team communication and draw out team interdependencies; • Implement PM tools or PM methodologies for team coordination. To better understand how these three leitmotifs – scope, communication and management – surfaced, reading the first entries of Chapter 5 might be needed. 54 5. RESULTS Amongst the challenges that come with taking a new job at a company, the ability to relate with one’s peers proves paramount to establish the reach of the newly acquired functions and access the breadth of the tasks at hand. If at first the researcher might benefit from the deference his novelty grants him, chances are that access to certain people and information will vary over time, as relationships grow beyond mere formality. In other words, the researcher’s point of view will become increasingly more influenced by the surrounding work environment. Therefore, such starting period is a proper, if not the best time to engage in the observational activity. This chapter is largely based on observational research into the project environment. Because the collected data is emergent it requires on-the-go analysis and constant researcher adaption in the best of the project’s interest. It is to say, diagnosis, action planning, and action-taking (intervention) coalesce into one another as events unfold. For comprehensibility, observation stages are presented in chronological order. Reflection boxes along the way provide further consideration about the project environment. Document analysis punctuates the observational account. In between periods, a summary of the taken action routes is presented. Finally, the results of a survey distributed to the project team gives further validation to the perceived project reality. 5.1 Observation, reflection and intervention 5.1.1 Prologue - LiDAR ART When starting this research, the researcher could not tell the difference between SC.LiDAR and its twelve project lines, and LiDAR ART, the Business Plan (BP) development stream of the same technology. Recognizing a Program Increment Planning Event (PIPE) was coming up in his first weeks at the office, the researcher decided to attend the event, and then a couple more, between November 2019 and April 2020. This subchapter entry encapsulates that impression. Bosch has started transitioning to Agile years ago, but it seemed not all development teams had adhered to the SAFE framework. Some said this was because they found out that the methodology pace did not sync with their development rhythm. LiDAR ART PIPE were set 10 weeks apart, with team sprints lasting for 2. The last (fifth) sprint was purportedly meant to innovate and plan the next PI, but in practice, many teams used it solely as a buffer to catch up with execution delays. Bosch puts up a lot of effort in providing the physical means for PIPE sessions to run smoothly. LiDAR ART was developed together with CC-PS 55 teams located in Schwieberdingen, so team stations were carefully set up in a large auditorium where the event was livestreamed to all. Each team had its own camera and sound devices to communicate with its other “half” back in Germany, when time for team level planning came. The PI Planning sessions were led by the RTE. Product Owner and Scrum Masters, the lowest coordination roles in SAFe, are overwhelmingly assigned in Germany. All upper responsibility levels, including System Architect, Product Management and RTE are in Germany too. On this regard, someone mentioned there was significant information filtering between Braga and Schwieberdingen. Reflection The researcher sat through a few of these PI sessions, the first one on November 26/27 2019. Communication during the PIPE seemed stiff, with most of the “action” happening “over there”. From the prevailing passiveness of the audience at Braga, it seemed the responsibility imbalance was either enforced or complemented by a mix of cultural differences and diverging interests between locations. Be it as it may, there were few or no experienced associates in the SM or PO roles to work with at Braga. Most of them did not work on SC.LiDAR anyway, so this would be a challenge if SAFe was to be tried out with the innovation project. From a theoretical standpoint, some shortcomings were observed in the application of SAFE to Business Plan LiDAR. Because it was virtually impossible to have all personnel physically present, occasionally, some people would travel in-between locations for PI Planning Events. It is questionable if the same results could be expected from such a virtual gathering, considering many of the associates in Braga kept a detached attitude throughout the sessions, e.g.: • Plenty of people would miss the session’s start (which was early and outside typical working hours); • Some people would keep coming and going out of the Auditorium for extended periods; • Some teams only had a couple of people present or were totally, physically absent (even if connected from elsewhere in the building); • A marketplace session, which was intended to have teams trading interdependent features, produced little to no results on the November 26/27 planning event; • Kanban boards were filled in Germany, but in some cases did not reflect the same in Portugal (or were left unused by the absent teams). No deeper inquiries were made as to why some teams opted out of SAFe. However, people working on hardware (components) expressed the nature of their job did not allow them to commit to a certain amount of work, at least, not as easily as software teams would. After failing to deliver a number of times, they decided to stop attending planning sessions, although it remained unclear how they coordinated with the ART from then. If indeed, their developing rhythm was much different from other teams, ways to inspect and adapt to their speed could be devised, to sync them with the remainder ART in a hybrid configuration. One central aspect of Agility is ensuring project transparency, process visibility, and top-down and bottom-up communication flow throughout the hierarchy. Such a mindset does not seem to be present. Not only process visibility seems disregarded by some teams in PIPE, but the role imbalance between locations also suggested decision power is centred in Germany, leaving Portugal in a subordinate, executional position. 56 Also, training sessions of Scrum and SAFe, guided by an Agile coach sent in from Germany, showed they were meant to be taught to software teams. For the average employee, with no AgPM background, it would be hard to relate to the given epic, story, and feature design examples. It is hypothesized that apprehending the framework logic and usefulness would be, thereby, complicated for people working on system or hardware functions. 5.1.2 December 2019 records Research kick-off meeting The first diagnostic phase started a few weeks after entering Bosch. The introduction to SC.LiDAR personnel happened during a meeting, the afternoon of December 4, 2019. This meeting was organized by the researcher’s mentor and its invitees included the project technical director (TD), the two main Functional Managers (FM), three project line responsible, and two PMO representatives. The actual attendee list includes at least two additional individuals besides the researcher himself. Later on, when asked why there were more attendees than expected, the researcher mentor (ENG6 team lead – Figure 24) answered that several people had shared the meeting invitation at their own discretion. As he saw it, this was in part a sign of genuine concern but also because some people felt like they needed back-up from some third parties. Throughout the meeting time, a couple of aspects became evident: • For one, different people addressed the issue that there was still no overall system architecture for the project lines to refer to. This is first brought up by ENG41 FM. • Simultaneously, there seemed to be an underlying animosity between some of the participants, coming from past events. • At a point, the TD expressed concern that in Germany, the Portuguese location interests (innovation projects) were being taken lightly. The same FM, a German national, uncomfortably laughs it off. • People shared different perspectives on what should be of this virtual project line, P00, and how to approach the line coordination effort. The meeting was held under the subject “ Sensible Car - LiDAR P00 next steps ” and its main determination was that the researcher would team up with the project TD to revamp the twelve project lines coordination. There was no preceding meeting agenda and no minutes were written afterward. The technical director’s strategy following this event was to meet all project lines, grouping them by development domain or scope affinity. Meeting times with both project line responsible and co-responsible 57 were sought, focusing initially on schedule and risk management (see Table 8). Because the TD availability was limited, him being involved in other affairs, the researcher opted to conduct some meetings on his own as the year’s end holidays closed in: Table 8 - First status meetings held by P00 with the other twelve project lines. Project line(s) Domain Meeting date Meeting coordination P08 + P10 Hardware (mechanics) 05/12/2019 TD + Researcher P01 + P04 + P12 Hardware (electronics) and Software 16/12/2019 TD + Researcher P02 + P03 Hardware (optics) 18/12/2019 Researcher P09 + P11 System testing 12/12/2019 TD + Researcher P05 Optics 17/12/2019 Researcher P06 Electronics 19/12/2019 Researcher P07 Electronics 18/12/2019 Researcher Meeting the project lines The very first of these meetings had a couple of project teams, P08 and P10, producing a development cycle schematic as shown on Annex 3. It was done together with their external Program peers (UM and PIEP) and displays three development loops, for which an estimated duration was found. It shows the natural sequence of large WPs and where other project line inputs are to be expected. It also shows how this all fits in the remainder project timespan. From the feedback gathered during the encounter: • Schedule management turned out to be one of the prevailing concerns. • Another recurring theme was that of individual team dependency on other project lines. Many team members saw the lack of definition in specific domains of the overall system design as a major hindrance and a risk hovering their own success. To different degrees, the attendees referred to the teams “at fault” in strained and exasperated fashion. Reflection Because parts of the overall sensor system were still to be defined, there was no product breakdown structure (PBS). This means no work breakdown structure (WBS) would be devisable either. The schematic shown by the teams (Annex 3) reflected the iterative nature of project work. They were aware that concept development could not be done linearly, thus development loops ran parallel for most of 2020 1st semester. There were Go/No go decision points (phase gates) where the sensor system 58 concept either proceeded or was abandoned. The 2nd semester of 2020 should be reserved for refinement of the winning concept. The large platform, laboratory, simulation (etc.) testing blocks might take from 3 to 6 weeks maximum. The team confirmed that these were estimations that did not account for delays. It should be noticed that many tasks, from part machining to numerical simulations, were done outside of Bosch. Those responsible for them were far from the researcher’s reach. The schematic’s development strategy seemed appropriate for the exploratory nature of the project, but the document itself was probably of no use for planning. To update a plan for a project already one and half years gone into execution, with an unknown number of interdependencies, might be an extremely challenging feat. It is noteworthy that, again, underlying tensions between different project lines became apparent and some team members seemed skeptical of the course the project had taken. On the meeting held with P09 and P11 a week later, a representative for each project line was present. Scheduling the meeting was not easy in the first place. Some of the responsible team members were uninterested or resisted making themselves available. They did write back, nonetheless, trusting their colleagues to voice their perspective and concerns. During the meeting, the responsible were defensive when asked for the reasons beyond these project lines issues and delays. There was a searing overtone to some answers as well, and often, the more vocal of the two members would rather make eye contact with the researcher than with the TD. The team said the difficulties they face included limited team capacity, lack of know-how on some technical topics, and having to deal with tasks they felt out of their responsibility: • Most of the project team was simultaneously working on another project (the BP LiDAR), which would compete for their working time. When asked by the researcher they explain the FM decided the allocation percentage for each team member. • P09 project charter included development tasks that were left there because no proper place was found at the Program start. The team struggled to address them. They should be getting the support of other PL, but no one had taken the lead still. • Some project acquisitions were made having the BP needs in mind. The team was concerned equipment specifications might be ill-suited to SC.LiDAR objectives. These issues came on top of a late project start. Actual work began nearly one semester after the Program's official kick-off - something the researcher’s mentor had alluded to on occasion. Reflection In retrospect, it is important to set apart technical and behavioral issues coming out of this meeting. State of the art in certain technical domains was still incipient, which is understandable considering the project innovativeness. From a management standpoint, only so much could be done other than 65 On the project server multiple document versions coexisted, therefore, the official ones were asked from the PMO. From PC analysis a level of redaction heterogeneity was evident. All Indexes were English, even if the documents were mostly written in Portuguese. Most of the signoffs happened as late as March 2019, although the Program had started nine months earlier. All PC were scanned, signed-off documents, except for P12’s. All included identification of the PL responsible, co-responsible and designated PM Officer – totaling six people, three from Bosch and their external counterparts. The same Bosch PMO was assigned to all LiDAR PL. There was no role and responsibility matrix, nor project governance definition. The information on Bosch representatives was outdated. Some fields were left incomplete (Annex 4). Overall, the project goals and expected results were loosely defined, even if concrete performance metrics were present. Besides the purpose of getting acquainted with each project line scope, the PCs were analyzed to see what references of the prototype sensor existed. As it happened, most PC mentioned prototypes at some point, but little to no reference of other project lines or their integration into a common prototype build. Reflection If the main objective of P00 Coordination was to have most of the 12 PL contributing to a single prototype, it seems odd that the PC did not reflect that purpose. Through inquiry with ENG42 functional manager, the researcher learned that the PC were, in fact, adaptations of an original, called “Anexo Técnico” (Technical Annex). This large, single document was the one that, upon submission to the sponsoring authorities, got approval for the SC Program. SC.LiDAR 12 PC were the outcome of breaking that content into more manageable bits, so they could be handled by smaller, dedicated teams. Furthermore, the researcher learned that the common prototype build was committed in the Technical Annex. In that document, it was referred to as Prototype A. Reflection Looking back at the charters, only P01, P02 and P04’s mentioned Prototype A. Speaking with P04 line responsible later on, the researcher would learn that reference was a last-minute addition to the charter. Also, even if without clear instructions coming from the PC, the team was developing a modular architecture for their electronics subsystem. It would allow adapting more easily to the other subsystems of the common prototype. A rushed translation of the Technical Annex into the 12 PC would explain why original English titling was preserved and, most importantly, why PL integration was left underdeveloped. 66 A striking detail was that some PC signatories no longer worked in SC.LiDAR, either because they were then on the BP or had since left the company. At this point the team composition was still unclear, however, there was at least a handful of foreigners working on the project. Their Portuguese proficiency ranged from basic to average, at best, which raised the question, how could they use the PC as working documents? P00 LiDAR coordination meeting from February 13 The February 13 coordination meeting had 14 people in attendance. 7 PL responsible and 7 team members. The project TD was invited but was not present. Each PL reported on their progress and spoke of the feedback they needed from other teams in order to advance with the work. The meeting agenda went over the pending tasks and defined new ones. Less than an hour before the meeting start, P09 responsible had called, asking to introduce a topic concerning system and subsystem testing. So, after nearly exhausting the planned meeting time, all there was to discuss is P09 last-hour addendum. The subject happened to be the same concern they had reported in December. There were tasks assigned to P09 for which they did not felt responsible. Support from P10 was agreed upon the signing of the PC and the line co-responsible was claiming it. The problem was that P09 was responsible for system-level testing once the final prototype became available. However, it was expected of them to test and know how to diagnose problems at the subsystem level. Besides, for this, they did not have the means or competence. The meeting devolved into a heated debate. At a point, the discussion became about the requirements for the sensor prototype, with people right, left and center arguing it had to be Automotive compliant or that it would never be Automotive compliant. The researcher and meeting organizer, collecting himself, put an end to the discussion, acknowledging both sides’ concerns, promising to go through the PC and readdress the issue the following week. As for the prototype requirements, he said that the ultimate goal would always be to develop an Automotive compliant technology. Even if, by the end of SC.LiDAR, the delivered prototype did not met those standards. 67 Reflection The number of people going to LiDAR coordination meetings was becoming unsustainable. The invitation list had 7 PL responsible and 1 supporting team member. The TD was invited but did not attend. It was a good sign that interest in the project status was picking up, but it was unmanageable to have so many people gathered, especially if they all wanted to speak. P09 responsible had an exalted intervention and was met with a similar response, not from P10 actually, but from P08 co-responsible. The PC had to be consulted to see what was said about system and subsystem level testing, and under which PL responsibility they fell. Also, special attention would be paid to references of development standards, Automotive or not. At this point, the researcher was already having individual PL meetings to check their scope and status (Figure 27– right side meeting blocks, in orange). Despite being overtime, P04 PL responsible had stayed behind the departing crowd. P04 Data Handling and Advanced Processing status was reviewed. When asked about potential roadblocks, issues with a supplier agreement and a specific decision that implied the optical subsystem were referred. The researcher vowed to escalate the supplier issue if needed and solicit commitment from the optical experts in the next coordination meeting. Upon finishing, the line responsible asked what the purpose of P00 was. It was explained that its purpose was to help coordinate all other project lines, among other things, by drawing out their interdependencies. The line responsible said that had already been done before. In the beginning of 2019, a P00 task force had been assembled with that same purpose. Before leaving, he pointed to some contents on the server, produced at the time. SC.LiDAR requirements and P00 detraction To clarify the requirements agreed for the LiDAR sensor prototype, the PC were consulted once more. There was barely any reference to development guidelines. Only P09 PC mentioned an ISO standard. Because there were concerns that the final system would not survive the strict automotive testing standards, which include e.g. rigorous temperature cycle or free-fall tests, the researcher looked for admission criteria in the texts (Annex 4). As mentioned before, because of the exploratory nature of this kind of project, both PL scopes and expected results were vaguely described. The expected results were not qualitatively set. For example, even when testing was referred, the goal was any result, whether the system passed the test or not. Unambiguously, P09, named LiDAR Evaluation and Testing Platform , had system-level responsibility for the complete prototype system. On the subsystem level, the other PC referred to testing activities, but did not explicitly address who would validate the PL results or through which means. The researcher summarized these findings in a presentation and invited all 12 PL responsible for a meeting on February 18. 68 Reflection It was important to clarify and help the teams prioritize project issues. This was an innovation project and as such, its scope was more explorative than directive. Some people were more prone to being told what to do, so they needed guidance in interpreting the objectives of their individual PL and of the common prototype build. It was important to instill a sense of responsibility, and PL responsible should be called to their own. Holding them accountable for leading the PL was a way of recognizing their authority so that they could become someone that team members would look up to. At this point, it was questionable if FMs had been enforcing this structure. The fact that it took so long to come forward with an optical subsystem concept, suggested responsibility was poorly defined or, at least, not enforced in practice. The issue with testing responsibility also showed that there was a problem in project design. There the message should be clear. Each PL should identify its testing needs and take responsibility for characterizing its results. They should look for the means to do so, not only in the project structure but across the organization and beyond it too. CC-PS had a manufacturing site nearby, with control of production and auxiliary testing labs. Besides, the project was co-promoted with UM and supported by a handful of other organizations. Yet, at the meeting of February 13 people behaved as if they had nowhere to turn to and no one wanted to take up the job. The other aspect to be addressed was prioritization. Some team members were concerned the final prototype system would not be Automotive compliant. It was important to frame their expectations and have them focused on delivering an MVP first. Several area experts believed that, from a technical standpoint, the final system requirements were a long shot from their current capabilities. The teams must then aim to a target up close. Only by practicing with short-range objectives could they gather the indispensable know-how that innovation requires. Getting that point across could be a challenge because openly admitting the project would not achieve the final system requirements could have a demoralizing effect. In resume, interesting research questions could be derived from this. What did people make of their PL requirements? Were they using their PL project charters for reference? The invitation to discuss SC.LiDAR requirements were sent through e-mail, to the project TD and all 12 PL responsible, which included ENG41 and ENG42 functional managers (Figure 28). Both of them were identified as responsible for P06. ENG41 FM was responsible for P09 but, in practice, P09 co-responsible had been showing up to P00 coordination meetings. 69 Figure 28 - Invitation to discuss SC.LiDAR testing requirements and responsibilities. This e-mail prompted an answer from P12 responsible, to which the researcher replied once, in order to amend for some misunderstandings. The feedback, however, was not reconciliatory (Figure 29). 70 Figure 29 - E-mail exchange with P12 line responsible. Reflection P12 competence area was software. Its scope was to provide software solutions that allow LiDAR prototypes to function. However, because it could not wait for SC.LiDAR prototypes readiness, its workflow would be mostly parallel to the bulk of PL involved in building Prototype A. As such, P12 neither was invited nor usually attended P00 Coordination meetings. The same happened with P03, P05, P06 and P07, for other reasons. Anyway, because SC.LiDAR requirements concerned all PL, it was important to promote and support a common interpretation of the project’s purpose. P12 responsible questioned the researcher’s interpretation of SC.LiDAR stakeholder dynamics. At this point, they remained somewhat unclear, as the addition of a new Project Management Officer to the coordinative structure illustrated. She mentioned the SC Program structure, although this only concerns the 12 LiDAR PL. From a behavioral standpoint, one could question why she chose to make this a public exchange. Besides keeping the TD and FM in copy, she added a PM Officer (BrgP/PJ-INV) to the distribution list. This was before that new associate was first mentioned. Her replies had passages written in bold (and highlighted in yellow). Even if the purpose was not to disparage the researcher’s approach, it is striking that first, she claimed her role should be marked as required, to subsequently acquit herself from that responsibility by refusing to forward the invitation to P12 co-responsible. Acknowledging this kind of transaction was unproductive and piled up in everyone’s inbox, it was better to leave it unanswered and personally approach her when possible. P12 co-responsible presence would be asked for in parallel. 71 In the hour leading to the meeting on February 18, the researcher decided to stop by P12 responsible desk and try to understand the animosity behind the e-mail replies. No notes were taken of the actual conversation. The researcher’s statement of intent and impressions about project reality were met with condescending observations in an ironic overtone. Unable to get to an honest exchange and feeling patronized, the researcher found it time to go and prepare the meeting room, excused himself and suggests continuing the conversation another time. At the meeting room, people were starting to gather. All PL responsible were present, including P12 coresponsible. ENG41 FM had come, whether as FM or P09 responsible was unclear. The TD was also present. The researcher started by thanking everyone’s presence and began with the presentation. After giving an overview of the first physical prototype sensor architecture and highlighting which PL were included or excluded from its definition, the requirements topic was introduced. He was stopped short by ENG41 FM, who asked if the LiDAR prototype would be built according to BES standards. This questioning from a senior figure in the project structure sent the researcher off-track, who in turn, looked to the TD for support. The TD answered the question and reminded all of the paramount need of having a first functioning prototype by the next Program audit, due in few weeks. This information shocked ENG41 FM who was unaware of such a requirement. The researcher proceeded with the presentation and stressed that the LiDAR technology emerging from the SC.LiDAR would always aim to be of automotive worth, even if that maturity would not be achieved by the end of the project. Before leaving, everyone was told to refer to their PL charters, and if they had any doubt, to get in contact with the researcher or the PMO. ENG41 FM talked to the researcher on the side and asked to meet him and the TD, immediately, about what would be needed for the upcoming audit. Reflection ENG41 FM intervention came off as a bit discouraging, as if to question the researcher's interpretation and approach to SC.LiDAR requirements. The question could have been rhetorical because a FM would know which standards the teams are referring to. If not all the teams, at least those under her responsibility. Her posture contrasted with that of other attendees. Some of these participants, who also had been in other project meetings where management was present, did not utter a word. It is striking that a team that felt so strongly about requirements’ definition did not pronounce itself when given the chance to discuss it with management. Early in January, during a P00 coordination meeting, the TD had set the goal of having a first functioning prototype before the Program audit, which would happen sometime between March and April. This was an internal agreement, as neither the Technical Annex nor the PC had such milestone defined. Because ENG41 FM did not frequently attend to P00 coordination meetings and, apparently, had not been reading the distributed meeting minutes, the information was new to her. This incident also revealed that information was not properly flowing at the upper management level. 72 ENG41 FM and the researcher gathered in a small room and, after awaiting the TD for some moments, decide to go through the purpose of P00 once more. The researcher said that he was looking for a chance to apply PM methods to improve coordination between SC.LIDAR PL. He recognized it was still early to go forward with a proposal. The physical prototype was discussed. ENG41 FM acknowledged the worth of the initiative and suggested that a recurring meeting at the management level should be held too, to align project priorities and support the researcher on his errand. She stressed the need of having a system overview of the prototype system. The TD had arrived in the meanwhile but remained inattentive for most of the conference. The researcher clarified that the physical prototype was not meant to be shown in the upcoming audit, which was just being taken as a reference to have a ready MVP. A LiDAR management meeting was set for the next weeks. Reflection ENG41 FM willingness to talk to the researcher and TD after the meeting is a positive sign. The research kick-off meeting left the impression that ENG41 FM and TD’s relationship was strained. Questioned about it, the researcher’s mentor (ENG6 team lead) said that, from what he knew, they would be on good terms one day or not speaking to each other the next one. These LiDAR management meetings could be a chance to observe and strengthen that bond, if possible. P00 Task Force Reflection If P00 had already existed before, it meant this research context was not the first time Bosch tried to align SC.LiDAR by eliciting the interdependencies between PL. The project server contained some presentations where the strategic purpose of the task force was explained. Its focus had been to provide the overall system architecture for the prototype sensor. The temporary team had been crossdisciplinary and had had 6 members, including ENG42 FM, the responsible for P03, P04, P10 and P12 line responsible and co-responsible. P10 responsible had since left the company. P03 did not integrate the common sensor prototype, but its responsible had been included as the optical expert. Some aspects of the proposed architecture became outdated since. The same could be said of team interdependencies. It would be interesting to know what had been made of this past coordinative effort. A meeting with the remaining task force members would be scheduled. 73 Figure 30 - Cover for P00 task force presentation. To the meeting held on March 4, P03 and P04 line responsible answered, as well as P12 line coresponsible. ENG42 FM and P12 responsible did not attend. The following notes were taken: - After some introduction, to confirm the purpose and acknowledge the work of the task force, the participants were asked why it seemed that work was of no consequence. P12 co-responsible said P00 had several meetings throughout 2019 then “for several reasons the PL diverged”. Asked to elaborate on those reasons, they mentioned e.g. limited team capacity, lack of focus, upcoming (individual PL) deliveries, and internal audits. P12 co-responsible added “some of them started working towards integration, others not so much”. - Upon being asked if they knew of the Technical Annex and what was committed with the project sponsors: “(it was) never shown to the teams”. - About the common prototype build and how its integration aspects were largely absent from the PC: “Prototypes already existed, at least implicitly, before the project charters sign-off”. The line responsible stated of P04 “(we) edited the PC to include prototypes and line testing (…)”. It was done to “include integration aspects absent from the initial version and also to secure support from UM side”. Reflection The assembling of a task force one year before the current events showed that management had long been aware of integration issues. That same management seemed to have failed to see through the task force results. As PL responsible testified, they had been unable to uphold that purpose because some PL, i.e. their members, did not abide by management directives, as things gradually reverted to 74 their former state. The teams did not have access to the Technical Annex, which meant they were reliant on the PC. The PC, in their turn, seemed to inaccurately translate SC.LiDAR scope. Interestingly, these task force members were present at the research kick-off meeting of December 4. It might explain why some opinions they shared that day were so strongly felt. These people were once invested in P00 and their work was, in some way, disregarded. P12 line responsible has not answered this meeting invitation. Her uncollaborative attitude could be rooted in a feeling of contempt towards the researcher’s purpose, which once was hers. The PMO and the Sensible Car audit An upcoming audit of SC had been a talking motive among project participants. Although it seemed natural to consider it in P00 coordination meetings, some stakeholders had a different interpretation. This motivated the following e-mail exchange between the researcher and his ENG6 colleague, who worked at the PMO. Figure 31 - E-mail exchange with PMO representative. 81 Figure 33 - Chronogram of meeting moments for May – August 2020 stage SC.LiDAR status survey On May 4, a questionnaire was sent to all project team members (Appendix 2). The questionnaire structure and its findings are presented in the 5.2 subchapter. This entry focuses on its reception and the stakeholder involvement around it. After confirming with FM and P12 responsible all team members’ names, some of whom the researcher never spoke to, an e-mail was sent asking for participation (Figure 34). 82 Figure 34 - E-mail to SC.LiDAR team with project status survey. By May 12, a third of the project team had adhered to the survey, however, answers had been piling up slowly since. Some weekly reminders had been sent in the meanwhile, and support from FM was asked. ENG42 FM quickly replied and asked his PL for participation in their next weekly meeting. Because P12 line responsible had offered to rally her teammates, ENG3 was also involved in deference. ENG41 FM, on her turn, required some insistence before asking her PL for participation. The TD would also be asked to e-mail a reminder to all team members because after nearly one month, adherence was not as high as expected. Reflection Relationship with ENG42 FM had been cordial. Both his and ENG41 FM agendas were quite busy, so they only showed up to P00 Coordination meetings very occasionally. Through project team members’ feedback, it was possible to confirm when they have asked their PL to answer the survey. It took ENG41 FM three weeks to address the issue with her teams, while ENG42 FM's action was much swifter. 83 At this point, ENG3 FM had been kept informed out of consideration. P12 line responsible was de facto responsible for the subproject, with her manager focus seeming to be on the BP only. After being inquired about team composition, she promptly offered to ask for P12’s team members’ participation. This contrasted with her initial unwelcoming stance. ENG3 FM eventually made himself available to do the same. However, despite the interest and assurance from both, the number of answers did not reflect the alleged full participation of P12’s team members. The TD was also asked to send an e-mail reinforcing the researcher’s call for participation. Which, after some insistence, he did. Both ENG41 FM and TD requests happened in late April and did not really influence the total number of answers. During the survey availability time, a team member shared some remarks about its contents. He found some questions too generic and others too technical. This was acknowledged and justified in an attempt to balance both the researcher’s reality and those of the respondents. While one section was inspired in traditional PM areas and uses typical PM terminology, another section provides more readily accessible statements, closer to what was understood to be the everyday experiencing of the project environment. The colleague also asked if some questions could have not been “downgraded from management level to associate level”. To this, it was replied that “ it’s everyone’s perspective at the associate/team level that’s so valuable to this process. When answering “How do you think the overall project management has evolved?” think of what matters to you, if you see meaningful change, for better or worse, that you understand management is responsible for ” . Besides him, a couple of colleagues asked for the researcher’s support to understand some terminology, while filling out the survey. Reflection Having to distribute the survey, made it evident that there was no visual project team structure for SC.LiDAR. The responsible FM oversight respects the logic of Table 6. The PC merely identified PL responsible and co-responsible at the project start. With the help of PL responsible and P12 coresponsible, an organogram of SC.LiDAR PL was elaborated (Appendix 3). Procurement management At this point, P00 Coordination was defined by the SC.LiDAR prototype build. This was the main concern around which the PL worked. Some subsystem features were being custom designed and made, but the concept remained much reliant on off-the-shelf components. This should be the fastest and cheapest route to proof of concept. But it also meant there was a big reliance on external parties to get the needed parts. 84 Bosch had specific procurement policies and procedures in place to ensure a compliant and lawful market search. Like other big businesses in the automotive sector, it adhered to quality standards that determine the use of certified supply chains. I.e. Bosch’s direct suppliers were all approved and ranked vendors. Sometimes, however, innovation’s unpredictability dictated the need of very specific components, unavailable at the standard supplier fold. In such cases, project team members had a standard supplier acting as a third party, who placed the order on their behalf. As it would be expected, this could delay the purchasing and arrival of parts. Furthermore, all purchasing needs seemed to be processed by a handful of people. Everyone, working on ENG41 or ENG42 teams, had only a couple of colleagues with access to the online buying platform, where purchase requests were placed. From there, these usually needed two management-level approvals before proceeding to a person who created all CC-PS purchase orders. From what has been observed, this process could typically take from a working day to more than a week. Reflection Trusting all purchase requests to a single person had its downsides. For one, it made the process much dependent on individual organization, with the risk of some orders falling down the processing list or even being forgotten. Although those few with access to the buying platform had designated proxies, it was hard to pass on task prioritization whenever such replacements happened. On the other hand, it made it unfeasible to sustain order tracking. Based on this research’s inquiries, neither the team associates nor the person closing the purchasing order process were used to track order status. Sometimes weeks would go by before word of a delay reached Bosch. Of course, this made it difficult to plan project activities weekly, both at P00 coordination meetings and at the individual level. ENG42 FM had been asked at some point if it would be possible to give platform access to all PL responsible, but this was answered negatively. LiDAR prototype B SC started on June 2018, but the first attempt at a common prototype build (prototype A) had only happened after the December 2019 optical concept. As per PC, both prototypes should be ready between the end of 2020 and 2021 first trimester. To prevent prototype B from dragging as the first concept did, some relevant stakeholders would have to be reunited to define possible concepts. A meeting was set to May 20. P01, P02 and P03 line responsible were summoned as optical experts. P04 responsible too, as the electronics interface expert. Besides them, the technical director and the two main FM were present. The meeting started by framing the development of Prototype B on the SC program scope. Only P02 PC explicitly mentioned it. Prototype B was supposed to build, partially, on top of Prototype A. The meeting 85 summarized two distinct approaches, however. P03 line responsible, the original proponent of Prototype A concept, argued most of it could be adapted. P02 line responsible, a reference optical expert, had P01 and ENG42 FM support in definitely departing from it. The latter option had still many uncertainties, which the optical team was trying to clarify through simulation tests. Both approaches implied some sacrifice of the final system specifications, as required by PC and Technical Annex. Reflection P01 line responsible and P03 co-responsible were the duo that has been doing most of the laboratory work on Prototype A. P03 responsible, albeit being the concept originator was 50% on BP and had less availability. It was evident the initial skepticism towards the concept still prevailed among his peers, even after weeks of hands-on experience with the physical set-up. P02 line responsible did not question the concept viability. Perhaps out of politeness for his colleague. Nonetheless, he did not believe it could be adapted to Prototype B specifications, with many of the attendants agreeing with him. The TD did not express an opinion in this regard neither did ENG41 FM, despite being responsible for both P02 and P03. P02 line responsible was 80% on BP, which meant that, theoretically, he only had one day per week to work on SC.LiDAR. He himself admitted it was very difficult to keep up with project demands. Despite it, the optical nucleus under his guidance came up with possible alternative concepts for Prototype B, which were under evaluation. It was agreed that work on Prototype A would continue as planned. The viability of its conversion to Prototype B would be simulated, as well as the alternative approaches that most of the team backed-up. The researcher agreed to track the findings on Prototype B concepts outside of P00 coordination meetings, which would remain focused on Prototype A. Reflection At that point, the alternate, off-the-record, concept for Prototype A had still not been publicized to all SC.LiDAR team. Informal networks Throughout this research, relationships were developed with some project team members. This entry is an account of accidental occurrences across the project space. P01 MEMS – microelectromechanical systems – had a crucial role to play on prototype definition. Therefore, its line responsible had been very close to P00’s coordinative effort. This optical engineer was 86 active, resourceful, had strong opinions, and kept a high commitment level. Naturally, she became a reliable source in helping to understand the intricacy of the whole prototype system. The cordial relationship between P00 and P01 started to change sometime around April 2020. On P00 weekly follow-up meetings, the researcher’s considerations and requests for information started to deserve some haughty remarks, even when not directly addressed at her. The impatient tone, verging on rudeness, was not valued at first, as it was thought to be some mood fluctuation. However, such behavior became increasingly apparent, also through hasted or declined phone conversations. At several moments, either on private or meeting times, she would question P00 concerns and legitimacy to intervene on certain topics. Reflection This kind of resistance to collaboration and sudden disregard for the researcher’s role and understanding of the project seemed unprecedented. In hindsight, there had been some underlying signs of a change in attitude. After the happenings described in Project transparency and clashes (p.78), the possibility of using P00 to distribute technical information to all project teams became a talking topic. At least on two occasions, P01 line responsible reacted defensively, as if P00 (i.e. the researcher) was trying to appropriate and take credit for other PL work. There was only one other occasion when such open resistance to P00 intervention was seen. Back in March, when the PLs were being met individually, an invitation was sent to P12. The purpose was to meet the subproject team, get to know them, review their objectives and goals, and see if there were managerial concerns they could be assisted with. At the time, P12 responsible vehemently rejected any chance of meeting, with the excuse that P12 had no dependencies with P00 integration prototypes. It did not go unnoticed that P01 and P12 line responsible, together with PMO representatives, could often be found together on their breaks, back when everyone worked from the office. Historically, it is known P12 responsible once worked for the PMO before coming to CC-PS development teams. Adding it to the report from The PMO and the Sensible Car audit (p.74), it could be that this collective was not keen on allowing P00’s interference in the project status quo . P05 New polarization concept – was an independent PL that did not participate in the common prototype build. Like other PL in this circumstance, it was being monitored, nonetheless. Its team composition included the line responsible and co-responsible, both assigned 20% to SC.LiDAR and 80% to the BP. The PL co-responsible was frequently being replaced by FM. An intern, assigned 100% on Innovation, completed team composition. Sometime around May, the intern approached the researcher, concerned his contract would come to an end the following month. He wanted to know about the chance of his continuity at the company. The 87 researcher told him he did not have information on it, but that he could, anyway, approach his FM (ENG41) and ask her about the prospect. The intern was told the concern for his future was legitimate, but it would take some encouraging talks before he got to do it. Reflection Noticeably, the intern was the only team member working fully on Innovation. This could mean his exit could significantly impact the team workload capacity. He was reluctant on addressing the issue with his manager. ENG41 FM would be asked if there would be continuity for him or if a replacement was being planned. As it turned out, she was completely unaware the intern’s contract was coming to an end. On a call, on May 11, she expressed surprise that his term had been so short. She expected it to be a year-long internship, instead of the contracted nine months. She would look into the possibility of extending the intern’s stay for a maximum allowed period of two months. Reflection The researcher, as an intern himself, knew this type of contract could take from three up to twelve months. He had looked up how many people worked under these conditions on SC.LiDAR, and when were their contracts due so that they could be adjourned, and their contribution acknowledged before the team ahead of their leave. As this instance shows, ENG41 FM appeared to be much focused on BP. In such context, it would be a legitimate concern to gather the PL team, or talk with the responsible, and understand how it would cope with the change before a certain member was gone. Despite her suggestion of having SC.LiDAR management meetings, ENG41 FM availability throughout the research was quite limited. She did not usually attend P00 coordination meetings. Furthermore, keeping her attention over the phone proved a challenge, as she would quickly dismiss any inquiry if she found the questions ambiguous or delivered unassertively. Although not publicized, it was known that she would be leaving the project in some months. Between May and June, an additional effort was put into reaching out to her. This was done to get to know how some project-specific topics were faring under her ward, especially concerning P09, for which she was still the formal line responsible (project team structure on Appendix 3). Calls with ENG41 FM were held on May 11, May 18, and May 27. On June 8, the researcher ventured some questions concerning SC.LiDAR management. Upon being asked how priorities were defined for balancing SC.LiDAR and BP workloads, she admitted favoring the latter. Not only the development pace was faster, because LiDAR ART had defined sprints, but its goals were also clearly set for each PI. She 88 saw Innovation more as if a “playground”, i.e. a sandbox, a project with relaxed requirements, where teams could “experiment more freely”. This was the last one-on-one talk with ENG41 FM before her departure. Reflection In a way, this corroborates that ENG41 FM was more aligned with BP objectives than those of SC.LiDAR. Because she is a German national, first admitted to the company in her home country, it was understandable that her priorities would be more aligned with the German location of CC-PS, rather than with the current (and temporary) Portuguese one. Additionally, this reverberated with a couple of instances, where at least two distinct ENG42 team members said that people working on Innovation strived to get to work on the BP. Judging by SC.LiDAR charters, several original PL responsible under ENG41 FM followed this course. Which could mean she had been using Innovation as a training ground, from where, in time, resources would be channeled to the more competitive BP environment. At the start of July, P05’s intern corporate accesses were deleted. This meant the associate had no access to his e-mail or any other company-sanctioned communication channel. His personal computer configuration and associated program licenses were lost too. Perhaps due to ENG41 FM own impending leave, the processes for the intern exit could not be stopped when a prorogation of his term was requested. He would stay working for SC.LiDAR until the end of August. This was not the last interruption affecting PL work, however. Because of the pandemic, Bosch countering measures included the possibility of doing home office for most associates. After a stabilization period, a phased return to the office started in June. By the end of July, the researcher learned that P05’s intern failed to return to the office and only had been at his station sporadically since. An ongoing argument between him and his P05 line responsible for working conditions had been going for weeks then. The intern himself reported on this. Reflection P05’s intern term extension seems to have been poorly managed, which yielded in the loss of working tools and the subsequent loss of work efficiency. The ensuing argument with his line responsible showed a lack of arbitration. P05 responsible inability to escalate the issue could be a sign that there was no replacement for ENG41 FM, now departed from the project, or that previously, that link with FM was not resorted to. From the diligences made, there was no apparent responsible for the intern’s actions within the project. Some opinions had it that in ENG41 FM’s absence, the TD would be responsible for the PL once under her supervision. This was suppositious, however. ENG42 FM was consulted but had no authority over the 89 matter either. The researcher eventually reached the BP team supervisor of P05’s line responsible, who decided to intervene and reach HR in this regard. HR then called the intern, demanding his return to the office the following week. Reflection Evidently, the contentious nature of the relationship between P05’s line responsible and intern had flown under management’s radar. This was suspected, months before these events, but because contact with P05 had been marginal (outside of the prototypes’ A & B build) not much was made of it. P05 intern would be back at the office on August 17. A meeting would be scheduled with the PL to broker an agreement between the clashing elements and organize the work for the remaining two weeks of the intern’s contract. These episodes, involving P01, P05, and PMO associates, illustrate how growing personal relationships can shed light on deeper project meanings and motives, and on what struggles may afflict proper project understanding and execution. Communication strategy ENG42 FM was deeply involved in the ideation, submission, and approval of SC. The personal stake he had in the success of SC.LiDAR was, therefore, higher than what could be expected of other functional managers. He was consulted frequently to make sense of the observed project reality. With ENG41 FM's departure from the project structure, it was expectable that his influence on the project’s direction would grow. Therefore, the actuation of the survey’s findings has been done in close collaboration with him. Based on the survey’s findings, i.e. the teams’ feedback (5.2 Survey), communication management was perceived as the area with the greatest potential for improvement. This agreed with the researcher’s impression of the observed project reality. As such, the researcher and ENG42 FM opt to rethink the meeting rationale for SC.LiDAR (Appendix 4). As it was, meetings limited to a single project line team or those of P00’s coordinative space, did not reach all stakeholders nor answer their information needs. Besides those work organization meetings, some people met sporadically in technical subsystem meetings. P00 coordination meetings, led by the researcher thus far, would give place to P00 Strategic and System Integration (Figure 35). Its scope would remain centered in the common prototypes’ evolution, with a 90 contribution of all relevant PL responsible. That way, the number of attendants was reduced and responsibility for representing the PL is centered in the line lead. A PMO representative would be invited to this meeting, to safeguard alignment with external stakeholders. Figure 35 - New meeting rationale - Strategic and system integration definition. Strategic and System Integration meetings should happen every two weeks, although they might be done weekly during the transition period. Feedback would be brought in from each PL from line coordination (Figure 36). The following figure expresses management expectations of what line responsible should organize at the PL level. No hard rule would actually be enforced, although a meeting frequency was suggested. Likewise, ENG42 FM expressed the want for the line responsible to fill a standard template with PL status. However, no standard format had been agreed when the research ended. Figure 36 - New meeting rationale - Line coordination definition. 97 Therefore, identifying potential ideas and preparing them for submission was a priority. They were also told the PC expected IR to apply to LiDAR technology. Reflection This first session with P05 showed that the team’s perception of their PL scope was still flawed, with the Bosch line lead proposing patent ideas that did not adhere to Sensible Car’s purposes. His strict demand for the University to share raw data seemed to take everyone by surprise. The lack of decorum in his demeanor could not go unnoticed as it could potentially harm the relationship between institutions. This incident illustrated there is room for individual competence improvement, if not of all, at least of this PL lead. Of course, the larger question here was if management at Bosch was aware of such shortcomings in PL leadership. It was also inevitable to think that Bosch could be left exposed by bestowing its representation on unseasoned team members, and that such stakeholders’ dynamics should be being overseen by someone higher up in the command chain. Lastly, diligences were made to understand why P05’s former intern, who had left the company weeks before, was present at the session. He had been promised a research contract to remain working on the project at the university, but this had not been formalized still. Considering the unamiable terms in which he departed from his supervisors at Bosch ( Informal networks – p.87), it is a risky decision to grant him access to the project without a legal bond. P11 meeting started without an agenda and jumped right into technical matters, which would take most of the available time. In the end, the UM’s PL responsible presented the audience with a challenge. He asked for potential new ideas to explore in future collaborations between institutions. Both UM and Bosch had been working on the prospect of future innovation programs, which would succeed SC. He gave an example involving optical filters, which many wrongly interpreted as being a support request for one of the already existing PL of SC. It took a while to sort out the misunderstanding. Eventually, someone asked if the challenge could not be a bit more specific, i.e., if from an “engineering perspective”, was there a problem they should be trying to answer to. The same participant said that sometimes “this type of project” felt like an impossible quest to check too many options. The debate went on for a bit longer. The team was dismissed having to search for new ideas for homework. No due date was mentioned for coming forward with them, however. Reflection The discussion between project participants at the end of P11’s meeting was much interesting to watch. It was a decal of the challenge’s innovation projects present when there is no clear execution path to follow. It also resonated with the difficulties that teams typically face in ideation processes, such as brainstorming. It seemed a bit worrying that no deadline was set for the call of new ideas. This was a widespread aspect of the observed meetings with the University. As stated before, there never seemed to be too great a risk that could not be downgraded, nor was there a sense of diligence calling for hard-line commitments. Even when ongoing tasks ran overtime, people reasserted the delays were 98 recoverable. But one could not help but ask, if delays kept piling up, what would happen when there was no buffer left, at the end of the Program? Resource management P09 – LiDAR Evaluation and Testing Platform – former line lead was ENG41 FM herself. In practice, the PL co-responsible had been the one working alongside P00 towards integration. This co-responsible complained about workload balance for SC.LiDAR and BP from the research onset ( Meeting the project lines, p.56). In addition, from May 2020 she assumed a new Scrum Master role on the LiDAR ART. From meeting attendance and through open talks with the researcher every now and then, it was clear she was increasingly unengaged with SC.LiDAR. P09 had several investigation routes. One of such routes mimicked what was being done in the German quarters of CC-PS until it was found to lead nowhere. ENG41 FM was the main liaison on the topic and, before leaving, conceived a strategy to redirect the PL towards its goal. One of the contemplated changes included the return of a project resource to the project structure. In a way, this was a kind of reposition, as the associate has been contracted through SC.LiDAR but worked on the BP. This transition was to happen the first weeks of September, but as it turns out, by late October 2020 the topics that awaited him were still to be picked up. P02 – OPA/DOE – was responsible for the optical concept of Prototype B. The line lead was a very knowledgeable engineer, who was mostly devoted to the BP, however. FM and TD had been adamant that he would remain on the project after the team restructuring, even if with the same limitations as before. Through informal talks ( LiDAR prototype B , p.86), it had been agreed to bring forth a concept for Prototype B sometime during September. This was later postponed to October. As late as December 2020, parts were still being ordered to advance with the physical build of the concept. Reflection The described instances show that, despite the intent, project resources continued detached from SC.LiDAR priorities. Reducing the split-head count seemed to have had a peripheral impact on the project development speed. For the last weeks of this research, a passive stance has had been adopted in advance of exiting the company, so no inquiries were made alongside management in this regard. 99 P00 Strategic and system integration The beginning of September, P00 Coordination meetings are replaced by Strategic and System Integration ones. The meeting series invitation is sent to most PL responsible by ENG42 FM, without the researcher’s former knowledge. The same happens for Project Status meetings, which have the full team structure in attendance. Reflection Theoretically, it was up to the P00 line responsible to set up these meetings, but FM got ahead and decided to take the lead here. Anticipating his own exit from the project, the researcher decided to not object to this. Any expectation he might have had of still directing these meetings was quickly put aside. ENG42 FM did not give up control of them. Even so, the researcher tried to remain an impartial critic of the format and would interrupt the meetings’ course to raise questions he understood the team should consider. For instance, it was not uncommon for the PL leads to lose sight of the meeting purpose and dwell in deep technical discussions. These would consume a lot of the available time and subject those not directly involved, or even knowledgeable on the field, to long waiting times. As meeting occurrences went by, this had another perceivable side effect. Even with the meetings being overtime, there was not enough time to speak of the second prototype (B), which seemed to be getting forgotten. Meanwhile, the alternate concept that management chose to develop off-record had been brought to light, and it would also compete for the available time and team resources. A file directory was set afresh in MS Teams for SC.LiDAR. During the first meetings, no one seemed willing to write down the ongoing tasks and research routes, and when compelled to do so, the records would not register things like the assigned person or the expectable due date. In this sense, it was a regress from the previous P00 arrangement. After the meetings, the researcher would revise (or compose) the online records and leave them for the team’s approval. Bills of materials (BOM) were proposed by some line leads and this was backed up. It helped to keep track of the prototypes’ concepts and allowed everyone to better see the overall component availability. In setting up Strategic and System Integration , ENG42 FM invited in all line leads directly involved in building prototype A, prototype B and the backup version. Even before BOMs were considered, he instructed P01, (P02), P04, P07, P08 and P10 to fill in the component specifications and status of each element of the prototypes’ subsystem. In parallel, he asked P01 line responsible to compile a system test list that the prototype systems would have to go through once completed. Noticeably, P09 and P11 were not readily included in meeting occurrences, nor were they told of the system testing list, despite system testing and end of line testing being, respectively, of those PL direct concern. Access to the file directory in MS Teams for P09 and P11 line leads was asked from ENG42 FM, but he declined the researcher’s request, arguing the leading team had to focus on prototype completion first. 100 Reflection In assuming the backup prototype concept as an open research route, P07 was added to the coordinative PL fold. Simultaneously, P09 and P11, which had been present in P00’s coordinative meetings, were left out of Strategic and System Integration ’s first months. It is questionable if the P01 line responsible should have been the one defining which tests ought to be performed when there were two PL specifically dedicated to the topic within SC.LiDAR’s structure. Even if they did not get a say on which tests were needed, something unlikely considering their scopes, they should at least know what was expected of their ability to test system performance. After commenting with P01 line responsible that P09 and P11 should be made aware of the testing list, ENG42 FM was talked to as well, in the same regard. He downplayed the need to give P09 and P11 immediate access to Strategic and System Integration’s file directory. Despite being responsible for all these PL, ENG42 FM seemed less concerned about some PL that were formerly under ENG41 FM ward. It can be that he was more focused on prototype building than on prototype testing. However, there was an inherent risk of keeping system testing PL ignorant for too long. When completing 2020’s last trimester, they would have only half a year to make any betterment or adjustment, until the end of the program. Regardless of P01’s line responsible intentions and the will of ENG42 FM, the researcher decided to make an offline copy of the system testing list and share it with P09 and P11. Its line leads were told that a status review of what they could or could not test would be held at the start of October. They were asked to criticize, propose and justify changes to the list, as well as to think of possible correction plans to recover from any delay they might be facing. Reflection As the last observational period went by, the researcher experienced a growing feeling of estrangement from the project. With the new meeting rationale, and with ENG42 FM taking over the coordination meetings, he was being stripped of what authority he once had. P00 was becoming more functional management and less project management. Despite the company’s instructions to favor remote home office, many PL leads, and the FM himself was frequently at the company’s facilities. This more than physical distance between the researcher and the team had grown ever since it became evident the pandemic came to last. Line leads were increasingly drawn to ENG42 FM and in having to report to him, they were less likely to share information with the researcher or would feel burdened if I asked to do so. The researcher discussed it with his own FM, who suggested maybe setting up his station next to the teams, but it felt too late for that. Even more so because it would be trying to compensate for access the researcher no longer had. As ENG42 FM was wrapping up the last meeting before the years ‘end holidays, the researcher intervened to address the team one last time. Besides the appropriate cordialities of the moment, they were left with two pieces of advice: • To make progress visible to their teammates. E.g. by taking pictures of the prototype set-ups in the build; to keep, update, and publicize records accessible to all. • To go across organizational boundaries and speak to each other, even when if it was not customary or expected of them. To try and let go of notions such as ENG41 and ENG42 and work as the unified brand Bosch is meant to be. 101 5.2 Survey In order to get a broad understanding of the challenges afflicting SC.LiDAR management, the thought of surveying team members came up. As explained to the team, this seemed a fair way of balancing everyone’s opinion about what needed to change. An anonymous questionnaire was set to collect feedback from all 38 project participants, working within Bosch, at the team level. The management structure was left out, despite the two main FM holding PL lead positions in the project organization. Team members working at UM and other external entities were not considered either, as this research increasingly focused on issues between the PL inside the company. The survey can be consulted in Appendix 2. It was subordinate to the subject “Agile vs. Classic Project Management in Innovation Projects – SC LiDAR status”. Although one of this research’s initial presumptions was to see how Agile or classical PM could be used to benefit SC.LiDAR, this questionnaire focused more on the latter part of the title: project status. The questionnaire was made available through a sharable MS Excel survey function. It was so to avoid using services outside of Bosch, which could compromise data protection. The downside of using such a tool is that it does not allow to narrow down questions. As such, the questionnaire is linear, and everyone is presented with the same set of questions. The questionnaire structure takes the PMBOK’s traditional management areas as reference. In the first section, respondents are asked to give their satisfaction level with each project management area, as identified by the PMBOK (questions 1.1.1 to 1.1.10). Still in this section, open questions are presented with the purpose of finding what project areas people find more critical (1.2 to 1.3) and what they believe could be further improved (1.4). A second section, also open question-based, tries to summarize people’s perception of recent past changes to PM practice within SC.LiDAR (2.1 to 2.3). Finally, a third section, provides twenty general statements about project reality, for respondents to agree or disagree with. Introduction – sample characterization The survey was available from May 4 to June 3, 2020. A total of 23 answers were obtained in a universe of 38 possible respondents. This represents an adherence of approximately 61% (Figure 39). Gender and age distribution of the respondents can be seen in Figure 40. 102 Figure 39 - Survey adherence. Figure 40 - Survey respondents' gender and age distribution. Nationality and job function were marked as optional fields, to concede respondent anonymity, as some specific combinations would give away certain identities. Most respondents opted to leave those fields blank, so the data was not processed. Section 1 – LiDAR Innovation project areas The first questionnaire section presents the respondent with traditional project management areas or dimensions. Short project area descriptions were transcribed from the PMBOK for reference. In questions 1.1.1-10 a Likert scale applies to the selectable satisfaction level choices, which range from “Very 61% 39% Survey adherence Respondents Nonrespondents 13% 87% Gender distribution Female Male 38 103 Dissatisfied” to “Very Satisfied”. The scale includes a neutral option, which is meant to reflect a lack of opinion, but that can otherwise be interpreted as a lack of comprehension about a certain project domain. The results in Figure 41 show an overall positive trend for satisfaction level, with a majority of participants (>50%) being “Satisfied” or “Very Satisfied” across all project areas, except for risk (48%) and stakeholder (48%) management. In absolute terms, risk management gathers the greatest number of non-opinioned answers (35%), a result closely followed by quality, procurement and stakeholder management (30%). 0 2 4 6 8 10 12 14 16 18 Integration Management 0 2 4 6 8 10 12 14 16 18 Scope Management 0 2 4 6 8 10 12 14 16 18 Schedule Management 0 2 4 6 8 10 12 14 16 18 Cost Management 0 2 4 6 8 10 12 14 16 18 Quality Management 0 2 4 6 8 10 12 14 16 18 Resource Management 104 Figure 41 - Satisfaction level with SC.LiDAR management areas. In absolute terms too, the areas with the greatest number of “Dissatisfied” or “Very Dissatisfied” respondents are scope and communications management, where they account for 26% of total answers. Considering this roughly represents a quarter of two-thirds of all project team members, it is still slight evidence of managerial issues to act upon. To get further insight into the challenges of SC.LiDAR management, some open questions concerning these project areas were presented in continuity. The answers to question 1.2 “What area of LiDAR Innovation do you find most critical?” varied greatly. While some respondents mentioned more than one project area, others could not find an answer. To weigh in all responses, the qualitative data were analyzed for emerging themes (Figure 42). 0 2 4 6 8 10 12 14 16 18 Communications Mngmt. 0 2 4 6 8 10 12 14 16 18 Risk Management 0 2 4 6 8 10 12 14 16 18 Procurement Mngmt. 0 2 4 6 8 10 12 14 16 18 Stakeholder Management 105 Figure 42 - SC.LiDAR most critical project areas. Integration and scope management come on top as the most critical areas, with 43% and 39% answer occurrence rates, respectively. Integration issues can be exemplified by: • Respondent 4, that says “ Defining exactly what are the responsibilities of each line(…) ”; • Respondent 6 points to the “ Interconnection between different lines for a single prototype ”; • Respondent 7 talks of “ Combining all areas and deliver something that works(…) ”; • Respondent 12 mentions “ The coordination between innovation lines(…) ”; • Respondent 24 testifies that “ The interconnection between different lines is not ideal, although it has improved in the last months with the creation of P00 ”. Such issues are transmitted to project scope, through the absence or changeability that afflicts the common prototype system breakdown structure, as mentioned by: • Respondent 13, that states “ Optical is the most sensitive area to care about ”; • Respondent 16 worries about the “ Detection ” subsystem; • Respondent 23 mentions “ The RX development ” (detection subsystem). Some answers, specifically, enforce the idea that both these areas’ issues were entwined at the inception of SC.LiDAR: • Respondent 4 wrote it was so “ because on the beginning of the project there was no strategy to get the big picture of the overall project and to get each line working together(…) ”; • Respondent 6 reinforces that “ Most of the single project lines were not defined with an overall system in mind ” 106 This is in line with the observed findings on project reality within the period of January-April 2020. The data on system architecture references was further filtered to decompose its issues (Figure 43). Figure 43 - Detail for issues on Scope and Resource management areas. The same was done for resource management, the third most referenced critical project area (Figure 43). According to question 1.3 “Do you think it jeopardizes work efficiency?”, 57% understand these issues negatively affect work efficiency. This means a significant part of people did not get to elaborate on question 1.3.1 “If yes, can you explain how?”. Those who did, explain that, historically, SC.LiDAR resources have not been fully assigned to the project: • Respondent 3 says “ People that should be working 100% into Innovation are working as well in BP activities ”; • Respondent 5 finds that “ If people are working a bit on several different things it's hard to be concentrated and efficient ”; • Respondent 15 thinks a human resource deficit affects ideation processes and project execution as “ Fewer people working/thinking, less work done and ideas given ” and now “ workload is quite soft considering the people involved, but it was not the case at the beginning (…) ”. To wrap up the questionnaire’s first section, team members are asked what they think could be improved about SC.LiDAR (Figure 44). Just above half of the respondents (52%) identify communication management as an area for potential improvement. 113 Section 3 provides more nuanced insights into project reality, with answers hinting at issues surrounding scope (goals and requirements) and resource management (tools and priorities). Integration challenges are present too, particularly aspects of interrelationship and familiarity with the project structure. In this regard, it is also important to mention the survey’s adherence, which fell 39% short of full participation. Such absence can be rooted in a feeling of estrangement from the project’s purpose or structure. Otherwise, some project personnel might effectively be working full-time on other projects. Among respondents, there is also a widespread perception of risks hovering SC.LiDAR. Considerations about these dimensions will be made on the observational periods following the survey. Functional management and the TD will be approached to devise a new strategy to enhance communication management first and foremost. In time, the survey results will be presented to the team, and reform introduced afterward. The survey’s raw data is included in Appendix 7. 114 6. DISCUSSION To discuss research findings on SC.LiDAR management, it is important to put the project’s existence into perspective. Therefore, this chapter starts by addressing SC.LiDAR scope and how project perception seems to have formed around it. Because this case study is itself a piece of the project narrative, communication and information management take prominent roles, something that has also been enforced by empirical findings alongside the project team. These abstract project management areas were referential for the survey’s findings and have been taken from the PMBOK. A second subchapter summarizes the issues found to affect project line coordination within each area. It does not mean, however, that Agile or hybrid PM standards and concepts will be excluded from the discussion. Different aspects of project and innovation management, covered in the literature review, were also brought in for perspective. The third subchapter includes some considerations about the used research method. 6.1 The project in perspective SC.LiDAR was approved into existence as part of the wider SC program, in June 2018. Such approval was based on the submission of the Technical Annex, which included some technical description of the program goals, and traditional project elements such as high-level planning for the program or some detail on its governing mechanisms. This was later broken down into seventeen subproject charters (Figure 23), which were signed by representatives of the cohort institutions, Bosch and U. Minho, as late as March 2019. As a rule, the twelve LiDAR PC are signed by one responsible person and a proxy or co-responsible individual, from either side of the partnership. Supporting PMO structures exist on both sides too. From the onset, two functional managers (FM) from Bosch take prominence in the project structure, appearing as the main PL responsible in some cases, or having functional authority over a said person. This research's first observational period started in late 2019, early 2020, and evidence shows the project structure was polarized around two divisional silos, ENG41 and ENG42, headed by the referred FMs (Figure 49). One of the core issues with SC.LiDAR comes from its design. Before the SC program scope was split into distinct project lines, plenty of the involved stakeholders were aware of interrelationship issues. However, these ended being poorly reflected on the PC. Task division is not clear, with some PL having been assigned activities that fall out of their competence area. In fact, one of the program’s flagship purposes is to deliver two innovative LiDAR prototype sensors (A & B). But some of these prototype system 115 specifications, namely the optical subsystem, have been left out of any of the twelve PL charters. This issue is seen as critical by the project team (Figures 42 and 43). The system architecture was also mentioned by ENG41 multiple times ( Research kick-off meeting , p.57 and SC.LiDAR requirements and P00 detraction , p.72) and its impacts discussed with one of UM PM Officers ( The pandemic , p.77). Furthermore, it means system design has been dependent on an informal commitment between parties. Figure 49 - Interpretation of SC.LiDAR perception partition before the research’s onset. To address this, a task force or system engineering team was assembled in early 2019, with the twofold purpose of conceiving the system’s architecture and identifying dependencies among the twelve PL. Regardless of the delivered results, the project structure was insufficiently committed to such arrangement ( P00 Task Force , p.71). To some extent, each manager failed to uphold that vision for the project. In the absence of a clear, formal structure, monitored and controlled by a cohesive project management body, informal structures gained prominence. This drift from holistic stakeholder interests, as described by Swan and Scarbrough (2005), could have been undermining team cohesion and project identity from the start. Additional reflection of issues with project authority is patent in P12’s organization. With ENG3 FM seemingly oblivious to SC.LiDAR’s organization (Figure 49), leadership is effectively poured into a line responsible whose observed behavior is marked by insurrectional tendencies. Another fragility of SC.LiDAR stems from the inbuilt ambiguity of its scope. This was deliberately done to give room for creative solutions, and in some instances, to remove the pressure of hard performance metrics from, otherwise, very ambitious technical goals. The tradeoff is an increased propensity for 116 diverging interpretations of the project’s goals and the accompanying scope creep. Both sides of this double-edged sword have been observed on SC.LiDAR. Being a basic research project, it benefits from individual ingeniousness, as described by Satell (2017). The backup prototype concept, ideated by P01 line responsible ( Project transparency and clashes, p.76), proves this, by affirming itself as the main development route towards the end of 2020. On the other hand, events involving some project lines ( Coordination with UM , p.94) show that it is possible for a PL responsible to be proposing solutions that contradict the project’s “expected” results, just a few months away from its conclusion. Another instance of scope creep, which has not been previously mentioned, involves P10 – Additive Manufacturing Technologies . For much of its existence, this PL positioned itself as a hardware provider, without effectively trying to come up with innovative construction or material solutions for the prototypes. This omission in its results was realized by the researcher towards the end of the research (December 2020), upon re-reading P10’s PC. It stresses the need for management to regularly check adherence to the project’s scope. This is part of what leadership is meant to be, and as Chesbrough (2012) and Dias et al. (2014) argue, it is a crucial competence to lead the team into achieving a project’s full potential. Considering the above, this research argues that interpreting such complex scope features cannot be left to the team’s sole discretion. It is one of the instances where project leaders ought to have a more directive kind of style and lead by example (Jung et al., 2003). Leadership, authority and organizational structure A directive kind of style was indeed adopted by the project’s technical director (TD) in the research early weeks. His push for a first optical concept and functional prototype ( Meeting the project lines , p.56, SC.LiDAR requirements and P00 detraction, p.66) seems to have kickstarted P00’s coordinative purpose. His presence, however, became increasingly scant as the year progressed. It is unclear if it had always been like this. From what little feedback was sought on the matter, it appeared to be so. But, perhaps, his divergences with ENG41 FM had been more detrimental to his authority over the project structure. What is granted is that coordination and communication between the two had broken down several times, as directly witnessed or reported by third parties. Arguably, the failed setup of LiDAR Management meetings (p.74) illustrated an unwillingness to repair that link. Lack of authority has also tormented the researcher’s role, as P00’s line lead. Adopting a mediator role was useful to bridge the polarized structure that had formed around functional management. This is in line with findings from Blindenbach-Driessen and Van Den Ende (2010), to whom project leaders must 117 engage in coordinative and integrative efforts when working with functional organizations. When surveyed, the project team recognized significant improvements in communication and integration management, the latter being explicitly attributed to P00 (Figure 46). In hindsight, this might have worked because the team, itself, yearned for a neutral ground, where through dialogue, some PL were able to settle their differences. But with ENG41 FM’s exit, the project structure converged in ENG42 FM, which assumed authority over almost all project lines (as reflected in Appendix 4). Although P00's purpose carried on as strategic and system integration, the researcher’s role as line lead became somewhat redundant. As argued at the end of the last observational phase, ENG42 FM was now much better positioned to ensure monitoring and control processes. The team understood this intuitively. If they had to escalate an issue, for whatever reason, they had a direct, vertical line of reporting binding all PL together, which rendered the horizontal, projectized structure obsolete. Ideation, innovation and project transparency Innovation is dependent on ideation processes and the ability to combine new ideas into successful solutions. From a strategic standpoint, this requires the organization to be on the lookout for emergent solutions amidst its ranks. This is a challenging feat, in the sense that the wider a project structure is, the greater the number of voices to be listened to. When this research kicked-off, SC.LiDAR had nearly forty associates within Bosch (Appendix 3). While evidence suggested some people had been, if not completely, at least quite detached from the project structure (see Resource management, p.100), others showed an active interest in being part of a solution, judging, for instance, by the numbers joining P00 coordination meetings early on the research (see P00 LiDAR coordination meeting from February 13, p.66). As mentioned in the observational records, managing large assemblies can sometimes prove chaotic. Because, practically, there is no way to take in everyone’s opinion, at any instant, management must come up with a plan to guarantee most individual inputs are considered, at all times. Reflections on project awareness, from late March 2020, showed that no information routes were linking P00’s coordination, management, and individuals working at the PL ground level ( Project transparency and clashes , p.78). In the absence of formal ideation and communication processes, this required keeping team members engaged through a culture of trust and transparency. As Seeber et al. (2017) argue about the virtues of group brainstorming, its biggest accomplishment is teams’ convergence and acceptance of an idea. Group ideation helps to develop team spirit (Furnham, 118 2000). And as other authors complement, management, or facilitators, have an arbitrational role to play in setting the rules for participation and birthing of project solutions (Litchfield, 2008; Rossiter & Lilien, 1994). When P01’s line responsible came up with an alternate concept for a LiDAR prototype, the TD refused to make it a transparent process and, arguably, let it be scrutinized by capable peers ( Project transparency and clashes , p.78). ENG42 FM was complacent with this. If found out, it could potentially damage management’s relation with associates working under ENG41 FM leadership. Either conscientiously or not, keeping her in the dark, as had happened before (see SC.LiDAR requirements and P00 detraction , p.71), perpetuated a divisive example for the PL to reproduce amongst themselves. Setting up a transparent project environment is not only beneficial to innovation as it is a sine qua non - enabler of agile PM frameworks. As described in subchapter 2.1.1, transparency is one of the three founding pillars of Scrum (Schwaber & Sutherland, 2017) and visual workflow processes are principal to Kanban (Tarne, 2011). Developing an off-the-record prototype went against this premise. One of SAFe’s nine principles includes tapping into knowledge workers’ personal drive. Once again, to ensure engagement, leaders have to promote an environment of mutual influence, where people voice their opinion, needs and concerns (Knaster & Leffingwell, 2019). Although de-emphasizing the project’s formal hierarchy might promote ingenious ideas, like the described backup prototype concept, it is reasoned by Keum and See (2017) that more centrality and control during idea evaluation and selection processes, limit participant bias. Despite having a positive sign of the team’s ability to innovate, it is questionable if, in this instance, management upheld the project’s best interest, by judging, favoring and allowing the continuity of an idea that effectively sidelined part of SC.LiDAR’s structure. It can be argued that, either unconsciously or not, management partiality was still present in the last observational period of this research, when ENG42 FM decided to temporarily exclude P09 and P11 from the core line leading team, assembled in P00 Strategic and system integration (p.97). Feedback from the project team also revealed there were issues in sustaining an environment that favored idea creation and support within and among PL. Some project team members did not felt heard by their PL peers or distrusted other PL decisions (Appendix 6 – answers to 3.1.14 and 3.1.19). Communication management Naturally, amending SC.LiDAR’s transparency issues would have to pass through reform of communication. The survey’s findings revealed the project team was also sensible to the matter (Figure 44 and Figure 47). Literature both on project and innovation management preconizes this can be 119 achieved by either formal or informal means, i.e. by setting up explicit formal monitoring and control processes or by tacit changes to work culture and in individual behavior (Barbosa et al., 2020; Ylinen & Gullkvist, 2014). To address the perceivable and shared impression that SC.LiDAR had to improve its visibility and stakeholder engagement, the new meeting rationale (Appendix 4) was devised by the researcher and management (see Communication strategy , p.88). The relation between these formal meeting moments is meant to set the base for smoother information exchange and improved PL articulation. Table 13 shows how each meeting type relates to typical PM arrangements in established and hybrid frameworks: Table 13 - Meeting rationale relation to PM frameworks. External Follow-up This meeting, involving both institutions PMOs, functional management (FM) and the TD, resembles a steering committee or a product portfolio management body (where the products would be different PL deliverables), as defined in SG hybrid solutions, such as the one proposed by Sommer et al. (2015) or in scaled agile frameworks like Large Solution or Portfolio SAFe® (Scaled Agile Inc., 2019c). Strategic and System Integration This meeting, organized by FM, includes a core or Product Owner team (all relevant PL responsible) like the one defined in the hybrid PM solution of Schuh et al. (2018), which in turn, is inspired by agile PM arrangements like Scrum (Schwaber & Sutherland, 2017), Scrum of Scrums (Larman & Vodde, 2010) or Essential SAFe® (Scaled Agile Inc., 2019a). Project Status Project Status is the widest-reaching meeting moment, which gathers the TD, FM, all PL responsible and team members. In a sense, it is similar to PI planning in SAFe®. However, its current purpose is not to plan, but to give everyone an overview of SC.LiDAR’s progression. It is also meant to grant everyone a chance to speak up, raise issues or share ideas. Line coordination This is the PL or subproject team organization level. It could be that some PL could adopt AgPM methods, like Scrum or Kanban (Schwaber & Sutherland, 2017; Tarne, 2011), however, it is unlikely that, due to the different nature of their jobs, all PL could be synched into the same PMLC. As mentioned, establishing a core specialist team in Strategic and System Integration , shares the same inherent logic of AgPM frameworks. It is equivalent to the Product Owner (PO) team in SAFe® or the team delegates’ assembly predicted in Scrum of Scrums (Larman & Vodde, 2010). However, this research revealed SC.LiDAR is far from having a projectized structure and also that it has to deal with the limitations of poor role definition. In the absence of a PMg or conventional agile roles such as PO or Scrum Master (SM), a lot of pressure is put on each PL leading person. They may not have the competence or availability 120 to coordinate the subproject team and simultaneously be part of a core specialist team. This might prove particularly stressful for those working on SC.LiDAR and BP at the same time. These Scrum roles or equivalent functions, which the researcher tapped into during his participation on SC.LiDAR, should be present across the project structure. Their exertion ensures there is a servant-leadership to translate the project’s scope and instigate teammates towards its goals. There was an attempt to formalize participant responsibility and accountability, at least for meeting moments (Appendix 5), but the current management structure showed unfazed about it in the observed instances. Project Status meetings include everyone enrolled in product development. In such a way, they are similar to PIPE occurrences in the BP LiDAR ART. During the last observational period, only a couple of these happened. However, they seemed to be characterized by the same social inhibition first observed in Prologue - LiDAR ART (p.55). When formal moments like this fail to serve their purpose, the organization ought to reconsider their usefulness, and also, to question if work culture aspects might be hindering individual participation in knowledge exchange. Line coordination meetings have only been punctually observed, since the research’s main purpose was to foster coordination between, and not within, PL. Anyhow, based on the observed reality, it is unlikely that traditional PM practices, heavily reliant on planning and controlling, will work for team-level coordination. In fast-changing environments, like that of SC.LiDAR, it is difficult to replan through Gantt charts and keep track of shifting requirements (Karlström & Runeson, 2005). This is not only because it would be unfeasible for a single PMg or project coordinator to keep track of twelve distinct timelines, but because, as witnessed, SC.LiDAR is heavily reliant on outsourcing ( Procurement management, p.88), something that greatly compromised schedule adherence. It could be that some PL could operate in an agile-hybrid kind of manner, in which instance, it would involve a Product Owner team or a town hall coordinative space, as already set in Strategic and System Integration . In summary, the emergent coordinative logic of the new meeting rationale began to take on the form of agile or hybrid PM configurations. Dissecting an established scaled agile framework, such as SAFe®, reveals that its solution is somewhat similar to what agile-SG hybrids have to offer, as described in subchapter 2.1.3. Such PM formats are Scrum-based at the team level but will put on more complex layers. As one moves higher up, or horizontally, in the organizational structure and the number of directly involved stakeholders increases, additional roles and ceremonies will have to be added in, with the risk of the arrived PM solution becoming as strict or willfully deterministic as classic PM methods (Hohl et al., 2018; Putta et al., 2018). Hopefully, this research has left SC.LiDAR one step closer to have a working hybrid PM solution. However, management should further work on clarifying role expectations alongside 121 project staff, to fend off the effects of a potential unruly project environment (Nederveen Pieterse et al., 2019). This balance of formal process control is played against the need for agile (i.e. quick-reacting), self-manageable, and truly dedicated teams (Conforto & Amaral, 2016; Schuh et al., 2018). Such team composition is not compatible with some of the observed HR management practices observed. Despite steps taken towards their reduction, the existence of split-heads still persists. The diversion of expert personnel or key area specialists from SC.LiDAR to BP (see Informal networks , p.89) is likely to undermine Bosch’s CC-PS innovative endeavors, particularly those of the studied Portuguese location. Communication management is just a subset of many interwoven PM areas. Therefore, fixed information channels and communicational arrangements should be beheld as transient and tailorable too. There are no steady solutions for cross-team coordination, consequently, SC.LiDAR’s team members and management should continue to “experiment with multiple approaches and adapt” (Larman & Vodde, 2010, p. 199). 6.2 Main issues found and proposed solutions The main issues found to afflict SC.LiDAR project line coordination have been summarized according to project knowledge areas, as considered in the PMBOK. Table 14 shows current practices listed alongside the identified PM shortcomings. It also points to solutions that have already been set in motion, or that could be tried in future project iterations. Albeit some traditional project elements exist, such as the 12 PL Project Charters, there is no aggregate Project Management Plan nor an explicit project governance structure, with SC.LiDAR borrowing many of its procedures from organizational process assets or tacit agreements with external institutions. During this research, adaptability to AgPM solutions was also considered. Bosch’s onboarding process provides the basics of Scrum and Kanban. Despite it being a good starting point for future work organization, most SC.LiDAR personnel was oblivious of such practices and did not apply them on a daily basis. Nonetheless, it is argued that the defining features of most common frameworks, such as project transparency and workflow visualization, could contribute to the betterment of project communications, yielding greater knowledge creation and exchange. Observation of BP LiDAR ART suggests that such Agile mindset has not taken root. Once it does, application of formal AgPM frameworks, such as team-level Scrum, and even scaled Agile, should be easier. Naturally, this would imply a different approach to project management, de-emphasizing the functional organization and selecting a hybrid PMLC. Such effort could be guided by the elements of CC-PS’ divisional directive CC-DD0301-2 Project Management. 122 Table 14 - Identified SC.LiDAR PM practices, issues and possible solutions. PM Knowledge Area Observed practices Observed issues Suggested solutions and remarks Integration management • Project Charters are available. • Underdeveloped project management plan elements (see other knowledge areas for detail). • Loose roles and responsibilities. • Devise a responsibility assignment matrix, a stakeholder engagement plan or other less-traditional project artifacts to foster commitment and enforce accountability. Scope management • Requirements have been collected and are available. • Scope design does not fully cover prototype system needs. • Scope creep. • Feasibility. • Secure expert judgment during PC inception and check if subsystem features have clearly assigned PL teams to develop them. • Use PCs as living documents to monitor and control scope. Check if early presumptions still apply and negotiate project requirements with relevant stakeholders. Schedule management • Monthly high-level follow-up by the PMOs. • Underdeveloped schedule without technical milestones (Annex 4). • Preserve high-level program planning for reference. • Downplay microplanning in favor of working solutions (MVP). Focus on rapid, proof-of-concept prototyping. Cost management • Not applicable (N/A) • N/A • The SC program budget is managed through CC-PS PMO. Processes for cost management were not looked into within the scope of this research. Quality management • Various organizational process assets exist. • Project deliverables’ quality control. • As reasoned before, quality control is entwined with the project’s scope control, validation and, therefore, its accompanying issues (see above). Resource management • Resources are managed outside of the project. • Clash over shared resources between SC.LiDAR and BP. • Reduce split-head count across the organization. • Select key-project contributors fully dedicated to innovation projects, as in successful AgPM approaches. Communication management • Project follow-up is done separately by PMOs (cross institutional) and FM (within Bosch). • Scattered subsystem technical meetings. • No defined communication routes exist linking the project team structure (other than functional bonds). • No project nor product documentation structure. • Identify and enforce formal communication channels, aided by the proposed meeting rationale. Adapt meeting model if needed. • Consider using specialized project follow-up and documentation software (e.g., SuperOPL, MS Project Server, Jira, etc.). Resort to bills of materials (BOM), component file identification and versioning in SC.LiDAR. Risk management • Monthly high-level follow-up by the PMOs. • Risk seemed to be downplayed during PMO follow-up meetings. • Innovative project environments are easily mutable, which asks for more quickreacting risk addressing strategies. Develop integration facets (interrelationship and communication) to address this. Procurement management • Organizational process asset for procurement. • Procurement process is much centralized, bureaucratic, and slow. • Consider developing a simplified, accessible procurement process for innovation projects that favors tighter order tracking and rapid prototyping. Stakeholder management • No holistic stakeholder view was identified. • Lack of project team identity. • Have a cohesive project management policy and body supporting all innovation’s PL (invest on integration management). 129 Dikert, K., Paasivaara, M., & Lassenius, C. (2016). Challenges and success factors for large-scale agile transformations: A systematic literature review. Journal of Systems and Software . https://doi.org/10.1016/j.jss.2016.06.013 Dodgson, M., Gann, D., & Salter, A. (2008). What is the Management of Technological Innovation and Why is it Important? In The Management of Technological Innovation: Strategy and Practice (pp. 1– 4). Oxford University Press. Donate, M. J., Peña, I., & Sánchez de Pablo, J. D. (2016). HRM practices for human and social capital development: effects on innovation capabilities. International Journal of Human Resource Management . https://doi.org/10.1080/09585192.2015.1047393 Duarte, R., Deschamps, F., de Lima, E. P., Pepino, A., & Clavijo, R. M. G. (2019). Performance management systems for project management offices: A case-based study. Procedia Manufacturing . https://doi.org/10.1016/j.promfg.2020.01.397 Edwards-Schachter, M. (2018). The nature and variety of innovation. International Journal of Innovation Studies . https://doi.org/10.1016/j.ijis.2018.08.004 Engwall, M. (2012). PERT, Polaris, and the realities of project execution. International Journal of Managing Projects in Business . https://doi.org/10.1108/17538371211268898 Enninga, T., & Van Der Lugt, R. (2016). The Innovation Journey and the Skipper of the Raft: About the Role of Narratives in Innovation Project Leadership. Project Management Journal . https://doi.org/10.1002/pmj.21578 Eppinger, S. D. (2001). Innovation at the speed of information. Harvard Business Review . Fernandes, G., O’ Sullivan, D., Pinto, E. B., Araújo, M., & Machado, R. J. (2020). Value of project management in university–industry R&D collaborations. International Journal of Managing Projects in Business , 13 (4), 819–843. https://doi.org/10.1108/IJMPB-08-2019-0191 Fernandes, G., & O’Sullivan, D. (2021). Benefits management in university-industry collaboration programs. International Journal of Project Management , 39 (1). https://doi.org/10.1016/j.ijproman.2020.10.002 Flick, U. (2015). Introducing Research Methodology: A Beginner’s Guide to Doing a Research Project. In SAGE . Furnham, A. (2000). The Brainstorming Myth. Business Strategy Review . https://doi.org/10.1111/1467-8616.00154 Gatignon, H., Tushman, M. L., Smith, W., & Anderson, P. (2002). A structural approach to assessing innovation: Construct development of innovation locus, type, and characteristics. Management Science . https://doi.org/10.1287/mnsc.48.9.1103.174 Gemünden, H. G., Lehner, P., & Kock, A. (2018). The project-oriented organization and its contribution to innovation. International Journal of Project Management . https://doi.org/10.1016/j.ijproman.2017.07.009 Goduscheit, R. C. (2014). Innovation promoters - A multiple case study. Industrial Marketing Management . https://doi.org/10.1016/j.indmarman.2013.12.020 Grbich, C. (2006). Qualitative Data Analysis: An Introduction carol grbich . SAGE Publications Ltd. Hagedoorn, J. (1996). Innovation and entrepreneurship: Schumpeter revisited. Industrial and Corporate Change . https://doi.org/10.1093/icc/5.3.883 Häggman, A., Honda, T., & Yang, M. C. (2013). The influence of timing in exploratory prototyping and other activities in design projects. Proceedings of the ASME Design Engineering Technical Conference . https://doi.org/10.1115/DETC2013-12700 Haneda, S., & Ito, K. (2018). Organizational and human resource management and innovation: Which management practices are linked to product and/or process innovation? Research Policy . https://doi.org/10.1016/j.respol.2017.10.008 Hart, M. A. (2012). The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create 130 Radically Successful Businesses Eric Ries. New York: Crown Business, 2011. 320 pages. US$26.00. Journal of Product Innovation Management . https://doi.org/10.1111/j.15405885.2012.00920_2.x Hauschildt, J., & Schewe, G. (2000). Gatekeeper and process promotor: key persons in agile and innovative organizations. International Journal of Agile Management Systems . https://doi.org/10.1108/14654650010312624 Heales, J., Susilo, A., & Rohde, F. (2007). Project Management Effectiveness: the choice - formal or informal controls. Australasian Journal of Information Systems . https://doi.org/10.3127/ajis.v15i1.480 Hidalgo, A., & Albors, J. (2008). Innovation management techniques and tools: A review from theory and practice. R and D Management . https://doi.org/10.1111/j.1467-9310.2008.00503.x Hobbs, B., & Petit, Y. (2017). Agile Methods on Large Projects in Large Organizations. Project Management Journal , 48 (3), 3–19. https://doi.org/10.1177/875697281704800301 Hoegl, M., & Parboteeah, K. P. (2006). Autonomy and teamwork in innovative projects. Human Resource Management , 45 (1), 67–79. https://doi.org/10.1002/hrm.20092 Hohl, P., Klünder, J., van Bennekum, A., Lockard, R., Gifford, J., Münch, J., … Schneider, K. (2018). Back to the future: origins and directions of the “Agile Manifesto” – views of the originators. Journal of Software Engineering Research and Development . https://doi.org/10.1186/s40411-018-0059z Holweg, M. (2007). The genealogy of lean production. Journal of Operations Management . https://doi.org/10.1016/j.jom.2006.04.001 Hox, J. J., & Boeije, H. R. (2004). Data Collection, Primary vs. Secondary. In Encyclopedia of Social Measurement . https://doi.org/10.1016/B0-12-369398-5/00041-4 Hunter, S. T., & Cushenbery, L. (2011). Leading for innovation: Direct and indirect influences. Advances in Developing Human Resources . https://doi.org/10.1177/1523422311424263 Hyett, N., Kenny, A., & Dickson-Swift, V. (2014). Methodology or method a critical review of qualitative case study reports. International Journal of Qualitative Studies on Health and Well-Being . https://doi.org/10.3402/qhw.v9.23606 Jang, J., & Schunn, C. D. (2012). Physical design tools support and hinder innovative engineering design. Journal of Mechanical Design, Transactions of the ASME . https://doi.org/10.1115/1.4005651 Jensen, C., Johansson, S., & Löfström, M. (2006). Project relationships - A model for analyzing interactional uncertainty. International Journal of Project Management , 24 (1), 4–12. https://doi.org/10.1016/j.ijproman.2005.06.004 Jiang, Y., & Chen, C. C. (2018). Integrating Knowledge Activities for Team Innovation: Effects of Transformational Leadership. Journal of Management . https://doi.org/10.1177/0149206316628641 Johnson, K. E., & Stake, R. E. (1996). The Art of Case Study Research. The Modern Language Journal . https://doi.org/10.2307/329758 Jung, D. I., Chow, C., & Wu, A. (2003). The role of transformational leadership in enhancing organizational innovation: Hypotheses and some preliminary findings. Leadership Quarterly . https://doi.org/10.1016/S1048-9843(03)00050-X Kalargiros, E. M., & Manning, M. R. (2015). Divergent thinking and brainstorming in perspective: Implications for organization change and innovation. Research in Organizational Change and Development . https://doi.org/10.1108/S0897-301620150000023007 Kalenda, M., Hyna, P., & Rossi, B. (2018). Scaling agile in large organizations: Practices, challenges, and success factors. Journal of Software: Evolution and Process . https://doi.org/10.1002/smr.1954 Kapsali, M. (2011). Systems thinking in innovation project management: A match that works. International Journal of Project Management . https://doi.org/10.1016/j.ijproman.2011.01.003 131 Karlström, D., & Runeson, P. (2005). Combining Agile methods with stage-gate project management. IEEE Software . https://doi.org/10.1109/MS.2005.59 Kaufmann, C., Kock, A., & Gemünden, H. G. (2020). Emerging strategy recognition in agile portfolios. International Journal of Project Management . https://doi.org/10.1016/j.ijproman.2020.01.002 Kawulich, B. B. (2005). Participant observation as a data collection method. Forum Qualitative Sozialforschung . https://doi.org/10.17169/fqs-6.2.466 Kelley, J. E. (1961). Critical-Path Planning and Scheduling: Mathematical Basis. Operations Research . https://doi.org/10.1287/opre.9.3.296 Kerzner, H. (2017). Project Management Organizational Structures. In Project Management Case Studies . https://doi.org/10.1002/9781119389040.ch4 Kerzner, H. (2019). INNOVATION PROJECT MANAGEMENT: Methods, Case Studies, and Tools for Managing Innovation Projects. In John Wiley & Sons, Inc. Keum, D. D., & See, K. E. (2017). The influence of hierarchy on idea generation and selection in the innovation process. Organization Science . https://doi.org/10.1287/orsc.2017.1142 Klarin, A. (2019). Mapping product and service innovation: A bibliometric analysis and a typology. Technological Forecasting and Social Change . https://doi.org/10.1016/j.techfore.2019.119776 Knaster, R., & Leffingwell, D. (2019). SAFe® 4.5 Distilled (Scaled Agile Inc., Ed.). Boston: Pearson Education. Kniberg, H., & Skarin, M. (2010). Kanban and Scrum-making the most of both. In Enterprise Software Development Series . C4Media Inc. Koskela, L., & Howell, G. (2008). The underlying theory of project management is obsolete. IEEE Engineering Management Review . https://doi.org/10.1109/EMR.2008.4534317 Kuprenas, J. A. (2003). Implementation and performance of a matrix organization structure. International Journal of Project Management . https://doi.org/10.1016/S0263-7863(01)00065-5 Laanti, M. (2014). Characteristics and principles of scaled agile. Lecture Notes in Business Information Processing . https://doi.org/10.1007/978-3-319-14358-3_2 Lahiri, A., Pahnke, E. C., Howard, M. D., & Boeker, W. (2019). Collaboration and informal hierarchy in innovation teams: Product introductions in entrepreneurial ventures. Strategic Entrepreneurship Journal . https://doi.org/10.1002/sej.1331 Lamm, H., & Trommsdorff, G. (1973). Group versus individual performance on tasks requiring ideational proficiency (brainstorming): A review. European Journal of Social Psychology . https://doi.org/10.1002/ejsp.2420030402 Larman, C., & Basili, V. R. (2003). Iterative and incremental development: A brief history. Computer . https://doi.org/10.1109/MC.2003.1204375 Larman, C., & Vodde, B. (2010). Practices for Scaling Lean & Agile Development (1st.). Boston, MA 02116: Pearson Education, Inc. Lee, Y. S. (2000). The sustainability of university-industry research collaboration: An empirical assessment. Journal of Technology Transfer , Vol. 25. https://doi.org/10.1023/A:1007895322042 Lenfle, S. (2008). Exploration and project management. International Journal of Project Management . https://doi.org/10.1016/j.ijproman.2008.05.017 Lenfle, S. (2016). Floating in Space? on the Strangeness of Exploratory Projects. Project Management Journal . https://doi.org/10.1002/pmj.21584 Lepak, D. P., Smith, K. G., & Taylor, M. S. (2007). Value creation and value capture: A multilevel perspective. Academy of Management Review , Vol. 32. https://doi.org/10.5465/AMR.2007.23464011 Leydesdorff, L., & Etzkowitz, H. (1998). The Triple Helix as a model for innovation studies. Science and Public Policy , 25 (3), 195–203. https://doi.org/10.1093/spp/25.3.195 Litchfield, R. C. (2008). Brainstorming reconsidered: A goal-based view. Academy of Management Review . 132 https://doi.org/10.5465/AMR.2008.32465708 Loch, C. H., Solt, M. E., & Bailey, E. M. (2008). Diagnosing unforeseeable uncertainty in a new venture. Journal of Product Innovation Management . https://doi.org/10.1111/j.1540-5885.2007.00281.x Maniak, R., & Midler, C. (2014). Multiproject lineage management: Bridging project management and design-based innovation strategy. International Journal of Project Management . https://doi.org/10.1016/j.ijproman.2014.03.006 Marrocu, E., Paci, R., & Usai, S. (2013). Proximity, networking and knowledge production in Europe: What lessons for innovation policy? Technological Forecasting and Social Change . https://doi.org/10.1016/j.techfore.2013.03.004 Maximini, D. (2015). The Scrum Culture. In The Scrum Culture . Springer. Maylor, H. (2001). Beyond the Gantt chart:: Project management moving on. European Management Journal . https://doi.org/10.1016/S0263-2373(00)00074-8 Melo, J. C. F. de, Salerno, M. S., Freitas, J. S., Bagno, R. B., & Brasil, V. C. (2020). From open innovation projects to open innovation project management capabilities: A process-based approach. International Journal of Project Management . https://doi.org/10.1016/j.ijproman.2020.06.006 Meredith, J. R., Shafer, S. M., & Mantel, S. J. (2017). Project management: a strategic managerial approach . John Wiley & Sons, Inc. Merriam-Webster. (2020). empowerment. Retrieved October 23, 2020, from https://www.merriamwebster.com/dictionary/empowerment Mintzberg, H. (1987). Crafting Strategy past of corporate capabilities and a future of market. Harvard Business Review . Miterev, M., Mancini, M., & Turner, R. (2017). Towards a design for the project-based organization. International Journal of Project Management . https://doi.org/10.1016/j.ijproman.2016.12.007 Morris, P. W. G., Pinto, J., & Söderlund, J. (2011). The Oxford Handbook of Project Management. In The Oxford Handbook of Project Management . https://doi.org/10.1093/oxfordhb/9780199563142.001.0001 Mullaly, M. (2006). Longitudinal Analysis of Project Management Maturity. Project Management Journal . https://doi.org/10.1177/875697280603700307 Naranjo-Valencia, J. C., Jiménez-Jiménez, D., & Sanz-Valle, R. (2011). Innovation or imitation? The role of organizational culture. Management Decision . https://doi.org/10.1108/00251741111094437 Nederveen Pieterse, A., Hollenbeck, J. R., van Knippenberg, D., Spitzmüller, M., Dimotakis, N., Karam, E. P., & Sleesman, D. J. (2019). Hierarchical leadership versus self-management in teams: Goal orientation diversity as moderator of their relative effectiveness. Leadership Quarterly . https://doi.org/10.1016/j.leaqua.2019.101343 Neuman, W. L. (2011). Social Research Methods: Qualitative and Quantitative Approaches. In Pearson Education . Norris, N. (1997). Error, bias and validity in qualitative research. Educational Action Research , 5 (1). https://doi.org/10.1080/09650799700200020 Osborne, A. F. (1953). Applied imagination: principles and procedures of creative problem solving. Charles Scribeners Sons, New York . Pennypacker, J. S., & Grant, K. P. (2003). Project Management Maturity: An Industry Benchmark. Project Management Journal . https://doi.org/10.1177/875697280303400102 PMI. (2013). PMI, (2013) A Guide to the Project Management Body of Knowledge (PMBOK Guide) (PMBOK Guide). 5th ed. Project Management Institute. In A Guide to the Project Management Body of Knowledge (PMBOK Guide) . PMI. (2017a). A guide to the project management body of knowledge (PMBOK guide) (6th ed.). Project Management Institute, Inc. PMI. (2017b). An Introduction to Agile. In Agile Practice Guide . Project Management Institute, Inc. 133 PMI. (2017c). PMI’s Pulse of the Profession® . Retrieved from https://www.pmi.org/- /media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pulse-of-the-profession2017.pdf Pollack, J., Helm, J., & Adler, D. (2018). What is the Iron Triangle, and how has it changed? International Journal of Managing Projects in Business . https://doi.org/10.1108/IJMPB-09-2017-0107 Poppendieck, M., & Poppendieck, T. (2003). Lean Software Development: An Agile Toolkit (The Agile Software Development Series). In Thinking . Porter, M. E. (1998). Clusters and the new economics of competition. Harvard Business Review , 76 (6), 77–90. Prior, L. (2007). Documents. In C. Seale, G. Gobo, J. Gubrium, & D. Silverman (Eds.), Qualitative Research Practice (1st paperb, pp. 345–360). Trowbridge, Wiltshire: SAGE Publications Ltd. Putta, A., Paasivaara, M., & Lassenius, C. (2018). Benefits and challenges of adopting the Scaled Agile Framework (SAFe): Preliminary results from a multivocal literature review. Lecture Notes in Computer Science (Including Subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics) . https://doi.org/10.1007/978-3-030-03673-7_24 Reagans, R., Miron-Spektor, E., & Argote, L. (2016). Knowledge utilization, coordination, and team performance. Organization Science . https://doi.org/10.1287/orsc.2016.1078 Ringham, C. (2019). Scrum workflow process. Retrieved May 9, 2020, from https://cringham.org/digitaldesign-journal/project-planning-the-software-development-way/ Robert Bosch S.A. (2019). Chassis Sytems Control. Retrieved November 19, 2019, from https://www.bosch.pt/noticias-e-historias/chassis-systems-control-jose-goncalves/ Robert Bosch S.A. (2020a). Bosch - Our Responsability. Retrieved November 28, 2020, from https://www.bosch.pt/en/our-company/our-responsibility/ Robert Bosch S.A. (2020b). Bosch no Mundo. Retrieved November 28, 2020, from https://www.bosch.pt/a-nossa-empresa/o-grupo-bosch-no-mundo/ Robert Bosch S.A. (2020c). CC-DD0301-2 Project Management (pp. 1–30). pp. 1–30. Robert Bosch S.A. (2020d). CD 04510 BES - Bosch Engineering System (pp. 1–7). pp. 1–7. Robert Bosch S.A. (2020e). CD 04510 BES - Bosch Engineering System Attachment 1: WO Requirements (pp. 1–17). pp. 1–17. Rosenthal, R., & Jacobson, L. (1968). Pygmalion in the classroom. The Urban Review . https://doi.org/10.1007/BF02322211 Rossiter, J. R., & Lilien, G. L. (1994). New “Brainstorming” Principles. Australian Journal of Management . https://doi.org/10.1177/031289629401900104 Royce, W. W. (1987). Managing the development of large software systems: concepts and techniques. ICSE ’87 Proceedings of the 9th International Conference on Software Engineering . Rubin, K. S. (2012). Essential Scrum. In Essential Scrum: A Practical Guide to the Most Popular Agile Process . Addison-Wesley. Satell, G. (2017). The 4 Types of Innovation and the Problems They Solve The 4 Types of Innovation and the Problems They. Harvard Business Review Digital Articles . Saunders, M., Lewis, P., & Thornhill, A. (2016). Research methods for business students (7th ed.). Pearson Education Limited. Scaled Agile Inc. (2019a). Achieving Business Agility with SAFe® 5.0. Retrieved October 3, 2020, from https://www.scaledagile.com/resources/safe-whitepaper/ Scaled Agile Inc. (2019b). Portfolio SAFe. Retrieved October 4, 2020, from https://www.scaledagileframework.com/portfolio-safe/ Scaled Agile Inc. (2019c). Solution Intent. Retrieved October 4, 2020, from https://www.scaledagileframework.com/solution-intent/ Schrage, M. (1996). Cultures of prototyping. In Bringing design to software . 134 https://doi.org/10.1145/229868.230045 Schuh, G., Rebentisch, E., Riesener, M., DIels, F., Dölle, C., & Eich, S. (2018). Agile-waterfall hybrid product development in the manufacturing industry - Introducing guidelines for implementation of parallel use of the two models. IEEE International Conference on Industrial Engineering and Engineering Management . https://doi.org/10.1109/IEEM.2017.8289986 Schultz, C., Salomo, S., De Brentani, U., & Kleinschmidt, E. J. (2013). How formal control influences decision-making clarity and innovation performance. Journal of Product Innovation Management . https://doi.org/10.1111/jpim.12009 Schwaber, K., & Sutherland, J. (2017). The Scrum Guide: The Definitive The Rules of the Game. Scrum.Org and ScrumInc . Scrum Alliance. (2020). Scrum overview. Retrieved May 7, 2020, from 2020 website: https://www.scrumalliance.org/about-scrum/overview Seeber, I., de Vreede, G. J., Maier, R., & Weber, B. (2017). Beyond Brainstorming: Exploring Convergence in Teams. Journal of Management Information Systems . https://doi.org/10.1080/07421222.2017.1393303 Shameem, M., Kumar, C., Chandra, B., & Khan, A. A. (2018). Systematic review of success factors for scaling agile methods in global software development environment: A client-vendor perspective. Proceedings - 2017 24th Asia-Pacific Software Engineering Conference Workshops, APSECW 2017 . https://doi.org/10.1109/APSECW.2017.22 Shenhar, A. J., Tishler, A., Dvir, D., Lipovetsky, S., & Lechler, T. (2002). Refining the search for project success factors: A multivariate, typological approach. R and D Management . https://doi.org/10.1111/1467-9310.00244 Sommer, A. F., Hedegaard, C., Popovska, I., & Jensen, K. (2015). Improved product development performance through agile/stage-gate hybrids: The next-generation stage-gate process? Research Technology Management . https://doi.org/10.5437/08956308X5801236 Swan, J., & Scarbrough, H. (2005). The politics of networked innovation. Human Relations . https://doi.org/10.1177/0018726705057811 Tarne, R. (2011). Taking off the agile training wheels, advance agile project management using Kanban. PMI Global Congress Proceedings – Dallas, TX . Newtown Square, PA: PMI. Teece, D. J. (2010). Business models, business strategy and innovation. Long Range Planning . https://doi.org/10.1016/j.lrp.2009.07.003 Tellis, G. J., Prabhu, J. C., & Chandy, R. K. (2009). Radical Innovation Across Nations: The Preeminence of Corporate Culture. Journal of Marketing , 73 , 3–23. https://doi.org/10.1509/jmkg.73.1.3 Tereso, A., Ribeiro, P., Fernandes, G., Loureiro, I., & Ferreira, M. (2019). Project Management Practices in Private Organizations. Project Management Journal . https://doi.org/10.1177/8756972818810966 Tierney, P., & Farmer, S. M. (2004). The Pygmalion process and employee creativity. Journal of Management . https://doi.org/10.1016/j.jm.2002.12.001 Toche, B., Fortin, C., Pellerin, R., & McSorley, G. (2017). A framework to support collaboration during prototyping and testing. International Journal of Product Lifecycle Management . https://doi.org/10.1504/ijplm.2017.10011416 Trott, P., Hartmann, D., Van Der Duin, P., Scholten, V., & Ortt, R. (2015). Managing Technology Entrepreneurship and Innovation . Routledge. Ugur, M., Churchill, S. A., & Luong, H. M. (2020). What do we know about R&D spillovers and productivity? Meta-analysis evidence on heterogeneity and statistical power. Research Policy . https://doi.org/10.1016/j.respol.2019.103866 Uludag, O., Kleehaus, M., Caprano, C., & Matthes, F. (2018). Identifying and structuring challenges in large-scale agile development based on a structured literature review. Proceedings - 2018 IEEE 135 22nd International Enterprise Distributed Object Computing Conference, EDOC 2018 . https://doi.org/10.1109/EDOC.2018.00032 VersionOne. (2018). 12th Annual State Of Agile Report . Retrieved from https://www.stateofagile.com/#ufh-i-423641583-12th-annual-state-of-agile-report/473508 Viswanathan, V., & Linsey, J. (2011). Design fixation in physical modeling: An investigation on the role of sunk cost. Proceedings of the ASME Design Engineering Technical Conference . https://doi.org/10.1115/DETC2011-47862 Wang, G. G. (2002). Definition and review of virtual prototyping. Journal of Computing and Information Science in Engineering . https://doi.org/10.1115/1.1526508 Will, M. G., Al-Kfairy, M., & Mellor, R. B. (2019). How organizational structure transforms risky innovations into performance – A computer simulation. Simulation Modelling Practice and Theory . https://doi.org/10.1016/j.simpat.2019.03.007 Williams, L. (2012). What agile teams think of agile principles. Communications of the ACM . https://doi.org/10.1145/2133806.2133823 Wysocki, R. K. (2019). Effective Project Management: Traditional, Agile, Extreme, Hybrid (8th ed.). Indianapolis, IN 46256: John Wiley & Sons, Inc. Ylinen, M., & Gullkvist, B. (2014). The effects of organic and mechanistic control in exploratory and exploitative innovations. Management Accounting Research . https://doi.org/10.1016/j.mar.2013.05.001 Zhang, J., & Wu, W. ping. (2017). Leveraging internal resources and external business networks for new product successA dynamic capabilities perspective. Industrial Marketing Management . https://doi.org/10.1016/j.indmarman.2016.06.001 Zorriassatine, F., Wykes, C., Parkin, R., & Gindy, N. (2003). A survey of virtual prototyping techniques for mechanical product development. Proceedings of the Institution of Mechanical Engineers, Part B: Journal of Engineering Manufacture . https://doi.org/10.1243/095440503321628189 136 APPENDIX 1 Schematics on SC.LiDAR prototypes as noted down by the researcher. 137 APPENDIX 2 138