I would like to express my heartiest gratitude and sincere thanks to my supervisor Andreas Riel for his trust in my abilities. He accompanied me from the beginning until the end in a very respectful, sensitive and professional way. I would like to express the deepest appreciation for his enormous support, guidance and advice that allowed me to surpass myself with respect to my scientific and professional career.

I would like to thank the Bayer Group for having made this thesis possible. Especially, I would like to express my utmost gratitude to my supervisor Tom Maes, Head of Product Supply Innovation Management. He gave me the idea of my research; and inspired and supported me every day with high commitment, encouragement and trust providing me the necessary freedom to explore my research questions in the context of the Bayer Group.

I also thank the G-SCOP laboratory at Grenoble Alps University for having accepted to host this thesis even mostly from the distance, and for having provided the academic framework required for bringing it to success.

Besides to my supervisors, I would also like to give special thanks to the members of the defense committee, Prof. Albert Albers, Prof. Jan van der Ende, Prof. Lionel Roucoules, as well as Prof. Michel Tollenaere for their acceptance to be in the jury, and for having critically studied my thesis.

Additionally, I would like to thank the team members of all the projects that I could accompany for their trust and excellent collaboration. Furthermore, my thanks go to all internal and external colleagues and friends supporting me through their highly informative and inspiring interviews and constructive feedbacks.

I would like to thank my parents Ulla and Konrad Brehm, who always believed in me, as well as my brother Markus and Karin. A big thank you goes to my friends, who often dispensed with me in the last three years, however always encouraged and inspired me with confidence.

And finally, I deeply thank my beloved husband Thomas. Without his patience and support, this dissertation would not have been possible.

To elaborate my thesis in cooperation with Bayer Group and the Grenoble Alps University was one of the best decisions I have ever made, and I am infinitely grateful for having had the opportunity of doing so. Thank you!

Résumé

L'incertitude fait partie intrinsèque de chaque projet, en particulier des projets d'innovation. Spécifications peu claires et changeantes, manque d'expérience et de compétences ainsi que les influences du contexte provenant entre autres des parties prenantes et de la législation ne sont que quelques sources typiques d'incertitude. En général, les niveaux d'incertitude ne sont pas répartis de manière homogène entre les tâches individuelles du projet. Le niveau d'incertitude d'une tâche, cependant, a une influence importante sur la façon dont cette tâche doit être gérée et exécutée. Dans la pratique courante, les chefs de projet, les équipes de projet et les outils de gestion de projet ne tiennent pas systématiquement compte de ce fait, ce qui conduit à des modes d'exécution de tâches inappropriés avec des résultats insatisfaisants et des conséquences négatives en aval du projet.

Dans ce contexte, cette thèse propose une nouvelle méthodologie pour inclure systématiquement l'incertitude et les considérations contextuelles dans la planification et l'analyse de projet du niveau macro (projet) au niveau micro (tâche). Il est basé sur la classification des tâches du projet en fonction de l'incertitude à laquelle elles sont confrontées. Pour y parvenir, ce travail identifie d'abord les exigences fondamentales des outils de gestion et d'aide à la décision facilitant la planification, le suivi et l'analyse de tout type de projets caractérisés par un niveau d'incertitude considérable. Basée sur un modèle de tâche qui intègre une définition de l'entrée, du résultat visé, de l'action ainsi que de son contexte sous la forme de parties prenantes impliquées, la méthode facilite la classification des tâches en fonction des niveaux d'incertitude estimés du résultat visé de chaque tâche par rapport à les entrées, ainsi que les actions de la tâche et son contexte. Le contexte peut être pris en compte systématiquement en utilisant un nouveau cadre de classification et de mesure du contexte dérivé des cadres existants pour capturer la complexité et l'incertitude du projet. Un langage de modélisation facilitant l'application pratique de ces modèles à l'aide des outils d'analyse et de visualisation des tâches ainsi que du réseau de parties prenantes a été mis en place.

L'ensemble du travail est basé sur une étude de terrain qui a été réalisée dans l'environnement de recherche industrielle du groupe Bayer Group pendant trois ans. Elle a été complétée par une recherche littéraire approfondie dans les domaines concernés. Les principaux moyens pratiques pour développer et valider les résultats sont des entretiens avec des experts, des ateliers et des formations, ainsi que le soutien actif et l'accompagnement des projets d'innovation chez l'entreprise.

Abstract

Uncertainty is an intrinsic part of every project, in particular of innovation projects. Unclear and changing specifications, lack of experience and skills as well as context influences coming from e.g. stakeholders and legislation are only a few typical sources of uncertainty. In general, uncertainty levels are not homogeneously distributed among individual project tasks. A task's uncertainty level, however, has a huge influence on how this task shall be managed and executed. In common practice, project managers, project teams and project management tools do not consider this fact systematically, which leads to inappropriate task execution modes with unsatisfying outcomes and negative consequences downstream the project.

In this context, this thesis proposes a novel methodology for systematically including uncertainty and context considerations in project planning and analysis from macro-(i.e., project) to micro-(i.e., task) level. It is based on classifying individual project tasks according to the uncertainty they are confronted with. To achieve this, this work first identifies fundamental requirements to management and decision aid tools facilitating the planning, monitoring, and analysis of any kind of projects characterized by a considerable level of uncertainty. Based on a task model that integrates a definition of the input, targeted outcome, the action as well as its context in the form of involved stakeholders, our tool integrates a task classification according to the estimated uncertainty levels of each task's targeted outcome with respect to its inputs, as well as the task's actions and context. Context can be taken into account systematically using a novel context classification and measurement framework derived from existing frameworks for capturing project complexity and uncertainty. A modelling language facilitating the practical application of these models using the task and stakeholder network analysis and visualization tools has been implemented.

The entire work is based on a grounded field study that has been carried out within the industrial research environment of the Bayer Group over three years, complemented by an in-depth analysis of research literature in the related fields. Expert interviews, workshops and trainings, as well as the active support and accompaniment of concrete corporate innovation projects have been the central practical means of developing and validating the results.

List of Acronyms

List of Figures

List of Tables

Introduction

Initial situation and context

Despite decades of innovation project management research and practice, a huge number of projects still fail in terms of not meeting their expected objectives or several key performance indicators (customer satisfaction, time, cost, etc.) (Project Management Institute 2017). In particular, innovation projects are characterized by managing novelty, risks and uncertainty. Embedded in a large corporate organization characterized by complexity and striving for stability, compliance with standards as well as efficiency and profitability presents a particular balancing act. While the project context is more dynamic and interconnected than ever before, traditional project management has stretched to its limits relying on project managers capable of predetermining the project execution in detail [START_REF] Hazir | A review of analytical models, approaches and decision support tools in project monitoring and control[END_REF]). This has led to an increase of more agile project management methods. However, dealing with uncertainty and evolving project needs does not follow the one size fits all methodology [START_REF] Shenhar | One Size Does Not Fit All Projects. Exploring Classical Contingency Domains[END_REF][START_REF] Balachandra | Factors for success in R&D projects and new product innovation: a contextual framework[END_REF]. Instead, innovation projects (IPs) require diverse project management methods (Ramasesh and Browning 2014a) to be applied appropriately in any particular project and context [START_REF] Cheema | Customizing project management methodology[END_REF], as well as applying them correctly over their life cycles [START_REF] Cockburn | Selecting a project's methodology[END_REF][START_REF] Locatelli | Systems engineering to improve the governance in complex project environments[END_REF].

Research problem

Established project management practices and tools fail both systematically and holistically considering the context and uncertainty [START_REF] Mcdaniel | Complexity Science and Health Care Management[END_REF]. At the same time, the context is becoming increasingly complex to capture, influence and predict, which boosts uncertainty to unprecedented levels. Following commonly used practices, project managers tend to stick to one specific project management method throughout the entire project lifetime and scope, without adequately considering varying levels of uncertainty over time and across project tasks. IPs not only require new combinations of resources, but also the involvement of globally structured stakeholder networks that provide access to complementary knowledge and perspectives, whose interactions entail further complexity. Therefore, the claim underlying this work is that the current simplification of the context is no longer appropriate, lacking a founded decisionmaking basis for deriving execution strategies. Moreover, there is currently "no conceptual model (…) that enables project managers to understand why different approaches exist, which one to choose, and when" [START_REF] Pich | On Uncertainty, Ambiguity, and Complexity in Project Management[END_REF], although there is the still a predominant drive for organizational stability, efficiency and control [START_REF] Howell | A project contingency framework based on uncertainty and its consequences[END_REF][START_REF] Brown | AntiPatterns in project management[END_REF][START_REF] Shenhar | One Size Does Not Fit All Projects. Exploring Classical Contingency Domains[END_REF] Against this background, Project Management Institute (2017) emphasizes that projects are more likely to succeed when they use tailored project management approaches. Continuously increasing and changing complexity demands for an approach that can identify and flexibly adjust methods that are appropriate to each project element and context throughout its life cycle [START_REF] Ciric | Agile Project Management in New Product Development and Innovation Processes. Challenges and Benefits Beyond Software Domain[END_REF]Ramasesh and Browning 2014b), and also apply them correctly [START_REF] Cockburn | Selecting a project's methodology[END_REF]. There is however a lack of practical decision aid tools that enable project managers within complex organizations to plan, analyze and track IPs in a highly uncertain environment [START_REF] Howell | A project contingency framework based on uncertainty and its consequences[END_REF].

Motivation and scope

The underlying motivation driving this thesis is to develop a systematic and practical approach that is based on classifying and approaching project tasks according to the conditions of uncertainty they are confronted with. Especially innovation projects in corporate contexts require managing novelty, risk and uncertainty within environments that in general strive for stability, efficiency and profitability. These challenging conditions characterize not only the early phase (e.g. fuzzy-front end) of innovation projects but also span across their entire life cycles. Against this background, the following fundamental research questions shall be addressed by this thesis:

1) What are the requirements for decision aid methods and tools that allow innovation project managers to plan, monitor and analyze IPs in uncertain environments? 2) How to implement these methods and tools in complex corporate environments? 3) What are their effects on the way innovation projects are executed?

The focus is on innovation projects in the sense that the include at least one element that is perceived as new, and which shall have a market spread. The latter may be internal on corporate level, as well as external outside corporate boundaries. Furthermore, uncertainty shall constitute a core element of my research as an integral part of innovation projects affected by risks and complexity. Project uncertainty shall therefore be captured holistically and investigated on both micro and macro levels of theorizing [START_REF] Crossan | A Multi-Dimensional Framework of Organizational Innovation: A Systematic Review of the Literature[END_REF]. Aspects such as leadership or organizational structures are less in focus, as they only affect but do not drive decisions.

The methodological approach chosen for this research is based on a grounded field study combining scientific literature studies with practical industry experience and experimental ground. This is largely due to the facts that an essential key requirement for this research was to deliver actionable results, as well as that the research environment has been a corporate one.

Thesis structure

This thesis consists of four main parts, as depicted in Figure 1-1.

Part I introduces the state of the art in literature in terms of the most relevant innovation project management topics for this thesis, particularly in project management, uncertainty management, and innovation management. The focus will be on the life cycle of innovation projects from understanding the problem to project implementation.

Part II defines the objectives and the methodology of this research. It proposes a holistic decision aid method and tool set for innovation project managers for managing projects under conditions of uncertainty as this thesis´ primary finding. This is called naviProM and is based on fundamental requirements derived from theory and practice. Five fundamental methodological elements will be presented in detail as well as their application.

Part III elaborates on the practical implementation and validation of the decision aid methods and tool set proposed in Part II to four diverse use cases in the context of the Bayer Group.

Part IV draws the conclusion of this thesis, analyzes its limitations and presents several perspectives for future research. The research field of innovation project management in complex organizations has been growing in importance over the last few decades [START_REF] Bakhshi | Clarifying the project complexity construct: Past, present and future[END_REF]. The literature review will exclude the subject of leadership, as the topic of this thesis is rather decision making of the project team and leader under conditions of project uncertainty.

My research is aimed at generating value in practice, as it is oriented to data with business-oriented background. Thus, my literature review exclusively aims for secondary data with business-related background. This limitation is reasonable because the term innovation is highly interdisciplinary, so an efficient and effective literature review needs a well-defined scope.

The Web of Science, ScienceDirect, and Springer were the main databases used in order to identify articles related to the topic, whereas Google Scholar was used for pre-research. In my research, I primarily rely on findings from the journals "International Journal of Project Management", "Business Venturing", "Production and Operations Management", "Journal of Engineering and Technology Management", and "Technovation".

The keywords used to identify titles and abstracts were, as a first step: "project uncertainty", "uncertainty management", "uncertainty measurement", "project complexity", "complexity management", "corporate entrepreneurship", "intraorganizational innovation", "breakthrough innovation", "new product development", "knowledge diffusion", "innovation ecosystem". As stakeholder networks are of particular relevance as an integral part of innovation project contexts, the keywords "innovation network", "network theory", "stakeholder value", "internal stakeholders", "intraorganizational networks" were added in a second step. All keywords were investigated in the context of innovation project management. To focus on internationally and peer-reviewed documents, I excluded conference proceedings and reviews and concentrated on articles in English.

In order to understand relevant terms, I investigated the origin of each term, their definitions and the areas they referred to. With respect to the state of the art, I investigated recent research findings as well as current research focus and gaps.

3 Complexity: Organization, Process, Project

Complexity

In the context of project management research there is no doubt that projects are becoming more complex. Despite extensive attempts to consolidate research based on the emergence of the term complexity [START_REF] Bakhshi | Clarifying the project complexity construct: Past, present and future[END_REF], the term's elements or types [START_REF] Baccarini | The concept of project complexity -a review[END_REF]) its sources and frameworks [START_REF] Rezende | Revisiting project complexity: a new dimension and framework[END_REF][START_REF] Abhari | Perceived Individual Risk of Coinnovation in Collaborative Innovation Networks[END_REF][START_REF] Xia | Complexity of information systems development projects: conceptualization and measurement development[END_REF][START_REF] Shenhar | Reinventing Project Management. The Diamond Approach To Successful Growth And Innovation[END_REF][START_REF] Vidal | Understanding project complexity: implications on project management[END_REF]Vidal et al. 2011aVidal et al. , 2011b;;[START_REF] Maylor | Managerial Complexity in Project-Based Operations: A Grounded Model and Its Implications for Practice[END_REF] there is no common understanding of project complexity, for example [START_REF] Bakhshi | Clarifying the project complexity construct: Past, present and future[END_REF][START_REF] Rezende | Revisiting project complexity: a new dimension and framework[END_REF][START_REF] Ireland | Exploration of Complex System Types[END_REF]. Given the high level of interest in research and practice, there are various distinctions - [START_REF] Baccarini | The concept of project complexity -a review[END_REF] differentiates organizational and technological complexity based on differentiation and interdependency. [START_REF] Williams | The need for new paradigms for complex projects[END_REF] further operationalizes the concept, including size interdependency and uncertainty, while [START_REF] Xia | Complexity of information systems development projects: conceptualization and measurement development[END_REF] refer to the multidimensional nature of project complexity differentiating between organizational/technical and structural/dynamic.

Thereby, there is a high degree of agreement about differentiating descriptive complexity (technology, structure, organization), including structural complexity based on interdependencies [START_REF] Baccarini | The concept of project complexity -a review[END_REF], and numerical complexity in terms of the multiplicity, diversity and dynamics [START_REF] Daniel | Complexity, uncertainty and mental models. From a paradigm of regulation to a paradigm of emergence in project management[END_REF][START_REF] Bosch-Rekveldt | Grasping project complexity in large engineering projects. The TOE (Technical, Organizational and Environmental) framework[END_REF]. Recent approaches have added softer aspects of perceived complexity and personal interaction based e.g. on trust, empathy, the individual experience and understanding [START_REF] Bosch-Rekveldt | Grasping project complexity in large engineering projects. The TOE (Technical, Organizational and Environmental) framework[END_REF][START_REF] Jaafari | Project Management in the Age of Complexity and Change[END_REF][START_REF] Geraldi | What complexity assessments can tell us about projects: dialogue between conception and perception[END_REF]. These allow consideration of micro-influencing factors such as behavior or the activities of individual actors next to macro-influencing factors [START_REF] Lu | Measurement model of project complexity for large-scale projects from task and organization perspective[END_REF]. Complexity is an important source of uncertainty in projects [START_REF] Martinsuo | Identifying, framing and managing uncertainties in project portfolios[END_REF]Ramasesh and Browning 2014a), since complex interrelationships render both the perception and prediction of a project action's effect much more difficult. [START_REF] Lu | Measurement model of project complexity for large-scale projects from task and organization perspective[END_REF] for instance point out the two central complexity types task and organization, which both cover structural complexity as well as interactive relationships of tasks and organizational actors (soft factors). They cover system thinking approach by referring to projects based on various tasks and participants, that cannot be considered individually. Tasks underlie sequential and reciprocal relationships as the outcome of a tasks serves as input of the subsequent or the former task. Thus, a change in one task automatically effects change in other tasks.

In system theory, complexity is considered as the property of a system that emerges as a state of interactions among its individual sub-systems [START_REF] Daryani | Management and Organizational Complexity[END_REF][START_REF] Mcdaniel | Complexity Science and Health Care Management[END_REF]. Thus, systemic behavior cannot be broken down just into the actions of its sub-systems [START_REF] Dekker | The complexity of failure. Implications of complexity theory for safety investigations[END_REF]. Transferred to innovation projects embedded in an organizational environment, this implies that they must not be considered as isolated [START_REF] Andersen | Do project managers have different perspectives on project management[END_REF]. A project can be rather perceived as a system that is embedded in the organizational system, both of which can be complex. Since a system is an object that, in a given environment, aims to reaching some objectives by doing an activity, while its internal structure evolves throughout time without losing its own identity [START_REF] Boulding | General Systems Theory -The Skeleton of Science[END_REF].

Organization

Following system theory, organizational complexity can be defined as the degree of interdependence among organizational elements, including divisions, units, departments, down to the level of individual stakeholders and resources they need as well as multiplicity, diversity and dynamics of organizational units [START_REF] Bosch-Rekveldt | Grasping project complexity in large engineering projects. The TOE (Technical, Organizational and Environmental) framework[END_REF][START_REF] Daniel | Complexity, uncertainty and mental models. From a paradigm of regulation to a paradigm of emergence in project management[END_REF]. [START_REF] Baccarini | The concept of project complexity -a review[END_REF] specifies that the greater the number of vertical (hierarchical) levels, and horizontal differentiation, including the number of organizational units and task structure (division of labor and personal specialization) and the higher the degree of operational interdependencies and interaction, the higher the organizational complexity is. In particular, large companies, structured in a matrix organization constitute a complex framework, including e.g. high diversity and number of stakeholders, processes or responsibilities. Against the context of new IP approaching new solutions, required expertise and decisions are not covered by already complex established roles, practices, set of expertise and knowledge and contractual frameworks. Therefore, IPs are not only confronted with difficulties based on structural complexity (e.g. search for experts, long decision-making paths), but also with organizational resistance, as established organizational norms need to be adjusted or eliminated [START_REF] Sandberg | What makes it so difficult? A systematic review on barriers to radical innovation[END_REF][START_REF] O'connor | A Comprehensive Model of Uncertainty Associated with Radical Innovation[END_REF][START_REF] Rice | Commercializing discontinuous innovations: bridging the gap from discontinuous innovation project to operations[END_REF][START_REF] Burgelman | Inside corporate innovation. Strategy, structure, and managerial skills[END_REF].

Process, Project

Given the organizational complexity, companies make use of two fundamental waysprocesses and projectsin order to achieve progress. Both are embedded in the organizational context in which organizational complexity constitutes one of several influencing factors.

Processes are a set of coherent actions that are to be carried out by specific roles and aim to achieving well-defined outcomes [START_REF] Niederman | Using Process Theory for Accumulating Project Management Knowledge. A Seven-Category Model[END_REF]). As such, processes represent a desired generic model of a subset of the real world. Their objective is to significantly narrow down the real organizational complexity to an easily understandable scale, such that they can be applied by all parties involved in a highly recurrent and outcome-oriented way. The most commonly used stage-gate process model [START_REF] Cooper | Stage-gate systems. A new tool for managing new products[END_REF], for example, reduces real-world complexity to a set of successive stages separated by decision gates, each of which have assigned roles and responsibilities.

Projects, by contrast, are unique, time-limited and one-off sequences of actions carried out by particular stakeholders. If I plan and manage projects according to a process, I must know that I am taking into account only a subset of the actual project complexity. Moreover, project complexity evolves over time, especially for innovation projects. Process complexity, however, remains stable unless the process is updated or redefined. Consequently, a dynamic project environment and continuous exploration of opportunities can foster dynamic complexity, requiring flexible and dynamic adjustment of project planning and management.

The individual amount of complexity can vary. The proposed decisionmaking framework in [START_REF] Snowden | Complex acts of knowing: paradox and descriptive selfawareness[END_REF] differentiates between four system types simple, complicated, complex, and chaoticrequiring different decisionmaking strategies [START_REF] Snowden | A leader's framework for decision making[END_REF]. In order to tackle the complexity of organizations, processes and projects, research proposes, and practice applies a more or less strong simplification by reducing both numerical and structural complexity in order to come from macro to micro level [START_REF] Lu | Measurement model of project complexity for large-scale projects from task and organization perspective[END_REF]. The most common approach is to divide the project into smaller structural elements (work packages, tasks) and considers only the most important relationships among these. Establishing a Work Breakdown Structure (WBS) is a very frequently applied pragmatic and structured approach that basically does just that. It allows for the defining and treating of individual work streams containing work packages, which are collections of individual tasks. Work packages and tasks typically capture major activities, effort/cost estimations, and responsibilities from the project manager's point of view.

This approach is effective in reducing the structural complexity for three reasons. First, it reduces the amount of interactions. Second, it assumes that the underlying complexity will not change. Third, it neglects any additional factors until work packages are finalized. On the other hand, it does not characterize work streams, work packages and activities in terms of their dynamics, interdependencies, uncertainties, and ambiguities [START_REF] Kiridena | Profiling Project Complexity. Insights from Complexity Science and Project Management Literature[END_REF]. Furthermore, it ignores the wider project context with regard to direct and indirect organizational, technical, environmental, etc. influences on the project.

Every projectand by consequence each of its work packages and activities is embedded in a very specific context that permanently evolves throughout the project life, faster and more frequently than ever before in today´s highly interconnected world [START_REF] Martinsuo | Identifying, framing and managing uncertainties in project portfolios[END_REF][START_REF] Böhle | A new orientation to deal with uncertainty in projects[END_REF]. This context, however, with its multitude of influencing factors, has a decisive influence on success or failure [START_REF] Perminova | Defining uncertainty in projectsa new perspective[END_REF][START_REF] Rezende | Revisiting project complexity: a new dimension and framework[END_REF][START_REF] Efatmaneshnik | A general framework for measuring system complexity[END_REF][START_REF] Engwall | No project is an island: linking projects to history and context[END_REF]. Furthermore, in case of frequently changing project needs resulting from experimentation and exploration in an uncertain environment [START_REF] Midler | Contributions of Design Thinking to Project Management in an Innovation Context[END_REF]) the existing project knowledge allows the detailed planning of the imminent work packages only. Consequently, there is a need to provide a means of relating simplified views on projects to their specific contexts and extending the usually manager-centric view to one view that takes into account a larger part of the organization influencing the project [START_REF] Hueske | What hampers innovation? External stakeholders, the organization, groups and individuals: a systematic review of empirical barrier research[END_REF].

Project contexts provide particular challenges for both theory and practice due to the variable levels of structural (scale, number of interdependent elements), socio-political (people, power, politics, agendas, relationships), and emergent (uncertainty and change) complexities [START_REF] Geraldi | Now, let's make it really complex (complicated)[END_REF]Ramasesh and Browning 2014a). Moreover, these complexities are not stable, but dynamic and therefore not entirely amenable to the logic of static development or manufacturing processes [START_REF] Browning | A Survey of Activity Network-Based Process Models for Managing Product Development Projects[END_REF]. Project-based and project-driven companies therefore impose particular challenges to factors determining success, in particular for innovation (Blindenbach-Driessen and van den Ende 2006). They also have different organizational configuration, a more complex operational process, and specific project management capabilities compared with functionally organized firms (Blindenbach-Driessen and van den Ende 2010).

Summary

Complexity in a project originates from both the project task structure and as the project organization. Project management approaches aim to reduce both numerical and structural complexity, the former in terms of the number of tasks/stakeholders, the latter in terms of their interdependencies. A common approach is to break down the project into work packages and tasks on different abstract levels that are related to the key stakeholders involved in them. This leads to a significant simplification of the actual complexity, which bears the danger of missing important relationships during project. This work grounds on this approach in order to assure high practical relevance, however it aims to augmenting it in a way that a more systemic method of structuring the project and its context is provided to the project manager and team.

4 Uncertainty as a Source of Ambiguity and Risks

Uncertainty

Broadly considered, uncertainty signifies the inability to predict both future actions and situations and their probabilities due to a gap between required and existing knowledge [START_REF] Olausson | Managing uncertain, complex product development in high-tech firms. In search of controlled flexibility[END_REF][START_REF] Spencer | Uncertainty, Expectations, and Foundations of the Theory of Planning[END_REF]). The term is not based on any common understanding [START_REF] Rezende | Revisiting project complexity: a new dimension and framework[END_REF] and has a comprehensive coverage in studies e.g. in mathematics (Bammer and Smithson 2009), of psychology (e.g. [START_REF] Kahneman | Variants of uncertainty[END_REF], complexity [START_REF] Lempert | Shaping the Next One Hundred Years: New Methods for Quantitative, Long-Term Policy Analysis[END_REF][START_REF] Weaver | Science and Complexity[END_REF]) and project management [START_REF] Loch | Managing the Unknown: A New Approach to Managing High Uncertainty and Risk in Projects[END_REF][START_REF] Perminova | Defining uncertainty in projectsa new perspective[END_REF][START_REF] Cleden | Managing project uncertainty[END_REF][START_REF] Meredith | Project Management: A Managerial Approach[END_REF]. In line with the lack of predictability, management and controllability and its consequences for traditional project management approaches, a particular research stream focuses on decision-making or project management under conditions of uncertainty in the system [START_REF] Demeyer | Managing project uncertainty: from variation to chaos[END_REF][START_REF] Ward | Transforming project risk management into project uncertainty management[END_REF][START_REF] Olsson | In search of opportunity management. Is the risk management process enough[END_REF][START_REF] Harris | Facilitating Innovation Through Cognitive Mapping of Uncertainty[END_REF][START_REF] Daniel | Complexity, uncertainty and mental models. From a paradigm of regulation to a paradigm of emergence in project management[END_REF]. These are for instance captured by determinants [START_REF] Saunders | Mapping the multi-faceted. Determinants of uncertainty in safety-critical projects[END_REF], as well as on sources of uncertainty [START_REF] Ward | Transforming project risk management into project uncertainty management[END_REF][START_REF] O'connor | A Comprehensive Model of Uncertainty Associated with Radical Innovation[END_REF][START_REF] Saunders | Mapping the multi-faceted. Determinants of uncertainty in safety-critical projects[END_REF]. Against the background of projects uniqueness (see Section 3.3), uncertainty constitutes a fundamental element of projects, as information can never be complete [START_REF] Hubbard | How to measure anything. Finding the value of "intangibles[END_REF]. It is all the more crucial to evaluate uncertainty in its context (i.e. [START_REF] Snowden | Complex acts of knowing: paradox and descriptive selfawareness[END_REF][START_REF] Bakhshi | Clarifying the project complexity construct: Past, present and future[END_REF][START_REF] Lechler | Challenging Classic Project Management: Turning Project Uncertainties into Business Opportunities[END_REF]. Hence, uncertainty management is closely linked with opportunity management, perceiving uncertainty as the necessary prerequisite of opportunities [START_REF] Loch | Managing the Unknown: A New Approach to Managing High Uncertainty and Risk in Projects[END_REF][START_REF] Lechler | Challenging Classic Project Management: Turning Project Uncertainties into Business Opportunities[END_REF][START_REF] Jaafari | Management of risks, uncertainties and opportunities on projects: time for a fundamental shift[END_REF]. Uncertainty is viewed as a perceptive phenomenon, as individual psychological profiles or perceptions affect rational decision making [START_REF] Kahneman | Variants of uncertainty[END_REF] through subjective interpretation [START_REF] Madsen | Taking a closer look at uncertainty[END_REF][START_REF] Head | An Alternative to Defining Risk as Uncertainty[END_REF]). In the field of risk and project management, there is a continued interest in the distinction of the terms risk, ambiguity and complexity [START_REF] Pich | On Uncertainty, Ambiguity, and Complexity in Project Management[END_REF][START_REF] Ward | Transforming project risk management into project uncertainty management[END_REF][START_REF] Sanderson | Risk, uncertainty and governance in megaprojects. A critical discussion of alternative explanations[END_REF].

Based on these definitions, I established my research on the following specification: Uncertainty represents the intangible measure of everything that is unknown about an operational task. This applies to the task's scope, its related activities, required technical and organizational capabilities, as well as to the 32 task's changing context. Hence, uncertainty may arise from inside the task, from outside it or from the individual interpretation [START_REF] Perminova | Defining uncertainty in projectsa new perspective[END_REF] It prevents project managers from making any objective predictions based on performance measures (cost, time, and quality). Thus, uncertainty hinders the determination of any cause-effect-relationships or the calculation of factors [START_REF] Ward | Transforming project risk management into project uncertainty management[END_REF], or events that have a negative (threat) or a positive impact (opportunity) on performance. Uncertainty therefore signifies the unknown unknowns in a project [START_REF] Rezende | Revisiting project complexity: a new dimension and framework[END_REF][START_REF] Ahern | Complex project management as complex problem solving. A distributed knowledge management perspective[END_REF]. Additional spectra of uncertainty are unknown knowns, known unknowns, and known knowns [START_REF] Winch | Managing Risk and Uncertainty on Projects: A Cognitive Approach[END_REF][START_REF] Sanderson | Risk, uncertainty and governance in megaprojects. A critical discussion of alternative explanations[END_REF][START_REF] Cleden | Managing project uncertainty[END_REF][START_REF] Demeyer | Managing project uncertainty: from variation to chaos[END_REF]. Uncertainty, therefore, contains the basis of ambiguity and risk (see Sections 4.2; 4.3).

Ambiguity

Ambiguity is defined as known unknowns [START_REF] Ahern | Complex project management as complex problem solving. A distributed knowledge management perspective[END_REF], the vagueness of facts, or decisions under uncertainty with regard to a lack of clarity and objectivity of relevant variables (lack of data, detail, or structure), their relationships and probabilities [START_REF] Schrader | Choice over uncertainty and ambiguity in technical problem solving[END_REF]. [START_REF] Pich | On Uncertainty, Ambiguity, and Complexity in Project Management[END_REF] refer to a project leader's lack of awareness or his subjective interpretations about relevant variables and their interdependencies. Ambiguity can be divided into interpretative ambiguity and normative ambiguity. Interpretative ambiguity refers to multiple interpretations of identical facts based on the subjective evaluation bases of the stakeholders involved. Normative ambiguity refers to multiple interpretations regarding the tolerability of identical facts based on different normative rules e.g., ethics [START_REF] Renn | Risk governance. Coping with uncertainty in a complex world[END_REF]. Therefore, ambiguity is a consequence of uncertainty [START_REF] Pich | On Uncertainty, Ambiguity, and Complexity in Project Management[END_REF][START_REF] Cleden | Managing project uncertainty[END_REF][START_REF] Olsson | In search of opportunity management. Is the risk management process enough[END_REF][START_REF] Perminova | Defining uncertainty in projectsa new perspective[END_REF][START_REF] Loch | Managing the Unknown: A New Approach to Managing High Uncertainty and Risk in Projects[END_REF][START_REF] Ward | Transforming project risk management into project uncertainty management[END_REF], or to put it another way, uncertainty is the source of ambiguities. To reduce ambiguity, necessary activities are focused on model building and testing as well as evaluation and reframing instead of purely on information gathering, interpretation, and integration for reducing unknown unknowns [START_REF] Ward | Transforming project risk management into project uncertainty management[END_REF].

Risks

Risks, by contrast, are considered as known knowns or knowable probabilities of occurrence [START_REF] Perminova | Defining uncertainty in projectsa new perspective[END_REF][START_REF] Ahern | Complex project management as complex problem solving. A distributed knowledge management perspective[END_REF]) that enable the predicting and controlling potential variations in performance. The estimation of probabilities often relies on available, statistical, and historical data as well as experiences. Risks are defined as factors (Project Management Institute 2000) that can positively and negatively affect performance in terms of cost, time, quality and other measures. Such factors can be circumstances, events, people, etc. Risk management aims to reduce measurable risks that can be identified, evaluated beforehand and are ultimately controllable (International Project Management Association 2006).

Applied to task management, uncertainty firstly leads to risks in task delivery. For instance, a lack of knowledge may relate to underestimated task effort, resources, or time. Furthermore, unexpected barriers, such as the lack of capabilities or resource availabilities, lead to risks in task execution. Secondly, uncertainty in tasks leads to ambiguity in the definition of tasks. Fundamental requirements, necessary actions, or the relevant task scope may underlie different perspectives that are insufficiently well accounted for.

Regarding the context, uncertainty can lead to risks in neglecting context in the execution of tasks. The task context is dynamic and changes during a project's life cycle. Risks may arise, e.g. in new regulations based on laws or resource restrictions based on the loss of suppliers or competing projects.

Moreover, uncertainty in context leads to ambiguity related to task definition and scheduling. A lack of knowledge about context factors could lead to e.g. underestimating the influence and attitude of indirect stakeholders (politics, legislation, competition, etc.) on the particular task and/or the entire project [START_REF] Ward | Transforming project risk management into project uncertainty management[END_REF].

By consequence, project management traditionally integrates risk management driven by quantitative methods and based on existing knowledge regarding the set of influencing factors, their causalities and required network of actions [START_REF] Green | Towards an integrated script for risk and value management[END_REF][START_REF] Ward | Transforming project risk management into project uncertainty management[END_REF]. Risk management is associated with task-centric planning, monitoring, and controlling. Non-predictable uncertainties, continuous learning and adaptations, or (changing) context conditions are typically not considered [START_REF] Atkinson | Fundamental uncertainties in projects and the scope of project management[END_REF]Ramasesh and Browning 2014b).

In order to reduce uncertainties effectively in tasks and their context as well as to increase responsiveness to change, traditional risk management needs to be complemented by more holistic uncertainty management. Research proposes integrating qualitative methods, making use of more agile approaches providing a higher degree of flexibility and adaptability to change [START_REF] Ward | Transforming project risk management into project uncertainty management[END_REF][START_REF] Daniel | Complexity, uncertainty and mental models. From a paradigm of regulation to a paradigm of emergence in project management[END_REF], as well as focusing completely on learning and understanding through experimentation rather than execution [START_REF] Sterman | Learning in and about complex systems[END_REF]. Furthermore, there is a consensus that projects require individual approaches to managing a task under specific conditions of uncertainties [START_REF] Charvat | Project management methodologies. Selecting, implementing, and supporting methodologies and processes for projects[END_REF][START_REF] Raz | Risk management, project success, and technological uncertainty[END_REF][START_REF] Atkinson | Fundamental uncertainties in projects and the scope of project management[END_REF][START_REF] Cooper | Agile-Stage-Gate. New idea-to-launch method for manufactured new products is faster, more responsive[END_REF]. Therefore, one central element of uncertainty management is to transform uncertainties into controllable risks as far as possible and project conditions by fact change during a project [START_REF] Böhle | A new orientation to deal with uncertainty in projects[END_REF]. This is consistent with Ashby's law of requisite variety (1957), which implies that in order to control a situation with a certain amount of variation, an approach with the same degree of variance is required. However, despite the increasing demand for uncertainty management approaches, an established holistic uncertainty measurement and management framework does not exist (i.e. [START_REF] Wang | Realizing value from project implementation under uncertainty: An exploratory study using system dynamics[END_REF].

Summary

Uncertainty means lack of information, which can differ in its sources, type, and extent. Uncertainty represents the unknown unknowns of an operational task, including its scope, related activities, required technical and organizational capabilities, as well as its changing context. Hence, it constitutes the basis of ambiguity and risk covered by established frameworks. There is a common understanding that the extent and evaluation of uncertainty depends on subjective perception. Nevertheless, a framework that formalizes and objectifies subjective human-biased evaluation does not exist. Furthermore, there is no adequate project management support for appropriately covering project requirements under conditions of uncertainty and change.

Innovation Projects and Corporate Entrepreneurship

Innovation and Innovation Projects

Innovation is typically associated with a particularly high amount of uncertainty, while being considered as a necessary condition of economic growth and competitive advantage to organizations (Schumpeter 1934;[START_REF] Tushman | Ambidextrous Organizations: Managing Evolutionary and Revolutionary Change[END_REF]. The term, which has been decisively shaped by Schumpeter (1934), is not based on any common definition. The key characteristics of any innovation is that it delivers something that is perceived as new and creates added value. This could be e.g. the development and use of new behaviors and solutions such as new products, services, business models or methods; a new market or organizational structure [START_REF] Damanpour | Research on innovation in organizations: Distinguishing innovation-generating from innovation-adopting organizations[END_REF]. Naturally, any novelty is linked with uncertainty. Incremental innovations aim to refine and improve existing technologies, products, etc. based on existing knowledge, and therefore imply lower uncertainty levels. Radical innovation leading to disruptions of established technologies, products etc. It requires the generation of new knowledge and by nature includes higher uncertainty and higher levels of risk (e.g. [START_REF] Tushman | Technological Discontinuities and Organizational Environments[END_REF][START_REF] Gatignon | A Structural Approach to Assessing Innovation: Construct Development of Innovation Locus, Type, and Characteristics[END_REF][START_REF] Teece | Explicating dynamic capabilities: the nature and microfoundations of (sustainable) enterprise performance[END_REF][START_REF] Nonaka | A Dynamic Theory of Organizational Knowledge Creation[END_REF].

Corporate Entrepreneurship

The certain innovation's project novelty (e.g. for the organization or the market) requires changes in the organization in which it is embedded in, and may cannibalize or conflict with established processes and standards [START_REF] Damanpour | Research on innovation in organizations: Distinguishing innovation-generating from innovation-adopting organizations[END_REF]. In order to get access to complementary assets and to prevent resistance or conflicting demands IP managers have to carefully integrate IPs by for instance, detecting affected areas and involving or aligning with diverse set of stakeholders [START_REF] Ireland | Conceptualizing Corporate Entrepreneurship Strategy[END_REF][START_REF] Hornsby | Managers' corporate entrepreneurial actions. Examining perception and position[END_REF][START_REF] Kreiser | Corporate entrepreneurship strategy: extending our knowledge boundaries through configuration theory[END_REF][START_REF] Greve | Networks and entrepreneurshipan analysis of social relations, occupational background, and use of contacts during the establishment process[END_REF][START_REF] Teece | Profiting from technological innovation. Implications for integration, collaboration, licensing and public policy[END_REF][START_REF] Vasconcelos Gomes | How entrepreneurs manage collective uncertainties in innovation ecosystems[END_REF]. Necessary stakeholder networks are not an existing constant. However, little is known about how temporary, unique, and dynamic IP networks evolve and influence IPs [START_REF] Kelley | Intra-organizational networking for innovation-based corporate entrepreneurship[END_REF].

In case that IPs are embedded in a complex organization (see Section 3.2) makes their implementation even more difficult. Established management practices not only partly contradict IPs, a complex landscape of practices and structures makes it further challenging to detect relevant processes, responsibilities etc. The management of the associated uncertainty is regarded as one of the most significant challenges of IPs [START_REF] Chawla | Antecedents and implications of uncertainty in management[END_REF][START_REF] Mckelvie | Unpacking the uncertainty construct: Implications for entrepreneurial action[END_REF]. Thus, in particular established organizations tend to struggle with the development of highly uncertain and rather cost-as well as time-intensive radical IPs [START_REF] Burgelman | A Process Model of Internal Corporate Venturing in the Diversified Major Firm[END_REF][START_REF] O'connor | A Comprehensive Model of Uncertainty Associated with Radical Innovation[END_REF]. They tend to make risk averse, conservative decisions, allowing incremental improvements by making use of existing resources, knowledge and predictable investments [START_REF] Dubois | Market size and pharmaceutical innovation[END_REF][START_REF] Tushman | Technological Discontinuities and Organizational Environments[END_REF].

Corporate Entrepreneurship (also Corporate Innovation, Corporate Intrapreneurship) is viewed as a multi-dimensional concept aiming at creating a supportive environment (e.g. freedom to experiment) for internal IPs and performing effectively in order to revitalize organization's established operations [START_REF] Ireland | Conceptualizing Corporate Entrepreneurship Strategy[END_REF][START_REF] Guth | Guest editors' introduction: Corporate entrepreneurship[END_REF][START_REF] Hitt | Strategic Entrepreneurship: Creating Value for Individuals, Organizations, and Society[END_REF][START_REF] Zahra | Goverance, Ownership, and Corporate Entrepreneurship: The Moderating Impact of Industry Technological Opportunities[END_REF][START_REF] Shimizu | Risks of Corporate Entrepreneurship: Autonomy and Agency Issues[END_REF][START_REF] Kuratko | Why implementing corporate innovation is so difficult[END_REF][START_REF] Lages | Intrapreneurship and firm entrepreneurial orientation: insights from the health care service industry[END_REF]. It includes the organizational commitment to entrepreneurial activities, the creation of new business and adaptation of its strategies [START_REF] Guth | Guest editors' introduction: Corporate entrepreneurship[END_REF]. Although its relevance for organizational competitiveness is acknowledged in science and in the industry, very few comprehensive frameworks exist how to implement IPs [START_REF] Ireland | Conceptualizing Corporate Entrepreneurship Strategy[END_REF]Dedehayir et al. 2016). [START_REF] Hampel | Beyond the lean start-up: experimentation in corporate entrepreneurship and innovation[END_REF] for instance, point out that more and more firms expand their experimentation activities from research and development (R&D) to customer related functions, providing time-limited programs or events (e.g. Hackathons, funding program) as well as innovation facilities (e.g. innovation spaces). These activities however exist isolated and in parallel to the established practices, while research and practice is lacking holistic approaches implementing innovation practices such as experimentation in the general operations (including innovation culture, tools etc.).

Summary

IPs are typically perceived as new, that is why they are characterized by an intrinsically high level of uncertainty. Hence, disruptive IPs in particular require project managers to make decisions under conditions of high uncertainty. Being embedded in a complex organization, makes IP management even more difficult, as its new approach and uncertainty contradicts established practices and conservative decision making. It is even more important that managers carefully consider the highly influencing stakeholder dimension as a potential source of complementary knowledge or source of resistance. Corporate Entrepreneurship is acknowledged as a multidimensional concept that aims to provide a supportive environment for an IP. Practice and research do, however, lack holistic approaches to support IPs from idea development to solution implementation.

Derived Requirements

Key findings from literature review

Based on the previous considerations, I can summarize some major shortcomings of current project management tools, especially regarding innovation projects involving a considerable level of uncertainty: S1) Oversimplification of the project structure by ignoring context and its temporality (dynamics). S2) Oversimplification of the project structure by ignoring task interdependencies and their temporality (dynamics). S3) Ignoring stakeholder relationships and influences. S4) Ignoring uncertainty sources from macro (i.e. project) to micro (i.e. task) level. S5) Ignoring uncertainty classification in terms of appropriate management and execution modes from project to task level.

Decision aid tool requirements

In order to address these shortcomings adequately, I define the following requirements to management and decision aid tools facilitating any kind of projects characterized by a considerable level of uncertainty in at least some parts of the project: Table 6-1: Requirements (1/2) Basically, these requirements call for a significantly lower simplification level compared to existing common methods and tools (WBS, Gantt, etc.). This, however, should not compromise practical usability, which is why we add the following two requirements to our further investigations: Q1) What does a method that fulfills the requirements RQ1-11 look like? Q2) How can this method be implemented based on tool support in an actionable way? Q3) How does this method influence the decisions of innovation project managers and their teams?

In order to elaborate on these questions, I start from the following central hypotheses:

H1) In general, uncertainty levels differ significantly within a specific project. Therefore, to appropriately capture uncertainty, project managers need to be able to identify, structure and analyze uncertainty levels down to task level. H2) A regular visualization and evaluation of uncertainty levels guide and inspire project managers in selecting different management and execution modes for each structural element. H3) Including the context in this activity, with a focus on stakeholders influencing the project and its structural elements directly or indirectly has an impact on project managers' decisions.

The methodology I pursued in order to address these research questions and hypotheses is based on a grounded field study. This is performed in the industrial environment of the Bayer Group over two years, complemented by an in-depth analysis of research literature in the related fields. Expert interviews, workshops and training, along with active support and accompaniment of a concrete corporate innovation project have been the central practical means of developing my results.

Research objectives

In the center of my thesis is the development of a decision aid tool addressing the presented research questions (Section 7.1). I therefore made use of IPs that had been carried out at the international life science company Bayer Group, which will be introduced in Section 7.3. To define the requirements to a method and tools supporting this method that adequately consider uncertainty, context and stakeholders over time throughout the entire project life cycle, I am not targeting a program or solution to be commercialized. Further, it must be possible to apply the decision aid tool sets within existing project management landscapes in various industrial settings with reasonable effort and in a reasonable time frame.

I therefore focused on the following primary objectives:  Development of a decision aid method and tool set for project managers that conceptually implements as many of the presented requirements (see Section 6.2).  Integration of practical insights into these methods and tools through very close collaboration with four innovation projects at Bayer Group (see Section 7.3).  Generalization of the gained insights and acquired knowledge, as well as derive patterns and integrate them in the method and tools.  Achievement of a long-term sustainability of the methods and tools at Bayer as a pilot user that is very much representative for the target group of this research.

Research context

The Bayer Group is a leading life science company founded in 1863, that has its competencies in the areas of health care and agriculture. In 2020, the company restructured its business into the following three divisions [START_REF] Bayer | Profile and Organization. Names, Facts, Figures about Bayer[END_REF]:

 Pharmaceuticals: Business includes prescription products, especially for cardiology and women's health care, as well as specialty therapeutics (e.g. areas of oncology, hematology and ophthalmology)  Consumer Health: Business focuses on non-prescription (over the counter) products in the dermatology, nutritional supplement, analgesic, digestive health, cold, allergy, sinus and flu categories.  Crop Science: Business is focused on seeds, crop protection and nonagricultural pest control. While Crop Protection/ Seeds includes seeds, innovative pest management solutions and customer service for sustainable agriculture, Environmental Science provides solutions for professional non-agricultural applications. With this divisional structure, shown in Figure 7-1, the Bayer Group generated sales of €43.545bn in 2019. The company invested €5.342bn in research and development expense. The global headquarters are in Germany. In its 392 consolidated companies active in 87 countries worldwide, the Bayer Group had 103,824 employees on December 31, 2019. 24,953 employees (24.0%) of total Bayer Group workforce were employed in Germany [START_REF] Bayer | Profile and Organization. Names, Facts, Figures about Bayer[END_REF].

Innovation, which is defined as "new solutions that generate added value for [our] company's customers and society" is addressed by strong research and development and through targeted process, service and business model innovations. In order to solve global business challenges in medical care and food security, innovation effort builds on the different, complementing approaches. The innovative capabilities of employees, the excellence in research and development, as well as a broad open innovation network. Further, the use of new, groundbreaking technologies and data science findings is implied (Bayer AG 2020a). To forward internal innovation there is e.g. one cross-segment entrepreneurship program providing financial and time-based resources and/ or methodical support by innovation coaches. They support internal innovation teams to develop their idea or insight from experimentation to implementation. In a period of three to twelve months teams apply innovation tools such as Design Thinking and Lean Startup along the innovation process [START_REF] Bayer | Experts and Enthusiasts Across Bayer[END_REF].

For a period of three years, I was part of the innovation team of Corporate Technology and Manufacturing which supported the board member responsible for production, supply chain, logistics, quality, as well as health safety and environment. In order to explore and to capture the established context of my research I was trained as an innovation coach and organized or participated in innovation activities. I enabled formal cross-divisional and cross-functional exchange through the organization of networking events, supported innovation projects focused on new technologies, participated in open innovation projects, and coached innovation teams. This was done in close collaboration with the innovation teams of the divisions and other corporate functions. The workshops and events that supported these activities got me in contact with business and innovation experts. Part of the innovation experience of my team and early results of my research is captured in the massive open online course (MOOC) "managing innovation: learning to prototype for business", which runs on FutureLearn.

For my research I accompanied and coached international innovation teams that participated in Bayer's corporate entrepreneurship program. This provided the opportunity to join the innovation journey from idea to implementation and far beyond. Thereby, I participated in pitching sessions and joined frequent decision-making meetings. While my research was developed in close collaboration with innovation teams and experts, the progress was shared via various internal and external presentations and the above-mentioned innovation MOOC. Moreover, I developed and conducted a training course in order to enable internal and external colleagues to apply research insights.

Research methodology

The development of a decision aid method and tool set seeks to connect theoretical principles and practice experience, in order to enrich both. I made use of an exhaustive literature analysis in the area of project management, innovation management, uncertainty management, and decision-making. In parallel, I observed and interviewed internal innovation project teams, and set up interviews with internal and acknowledged external experts in the area of innovation management and project management in order to identify and specify relevant gaps in research and practice. More precisely, I benchmarked proven project management methods with regard to their advantages and disadvantages under specific conditions as well as potential signals for switching an applied method.

Building on this, I defined and continuously improved my methodical concept in close cooperation with four IPs that I supported over a period of 1-2 years. Figure 7-2 shows the applied methodical approach. I refined the literature study and used expert interviews to develop a first concept. Based on expert feedback I detailed the concept and the method, which I then successively applied on the four IPs. The individually provided feedback and observations generated the necessary insights to first validate the concept. Second, I was able to improve the concept continuously as well as to identify new requirements. Besides, I asked the IP teams I had joined in the beginning of my research as well as innovation experts for feedback. In various iterations, I developed a decision aid method for project management under conditions of uncertainty, which I called naviProM (navigate in Project Management). Based on this industrial co-design I developed five complementing tools for several concept elements constituting naviProM:

 naviProM-Task  naviProM-Grid  naviProM-Compass  naviProM-Net  naviProM-Flow
This grounded field study approach ensured naviProM´s practical usefulness and holistic scope. 47 As illustrated in Figure 8-1, this task specification therefore consists of the following five fundamental elements: (1) its input, (2) its targeted outcome, as well as (3) the action(s) (4) the stakeholders shall perform under the influence of (5) the context. All these elements, in particular the task's context, evolve over time. The inputs are work products (such as resources, information) available to the task. The (actual) outcome is the tangible result once the task is finished. The outcome evaluation (OE) is based on the assessment of the actual outcome against the targeted outcome. This fundamental task model (RQ1) clearly goes beyond the commonly used task model describing the action and responsible stakeholder(s) only. Its purpose is to enable project managers to break down their projects into elements that allow the practical assessment of the task's uncertainty (RQ2) and use this information to plan and execute task execution accordingly.

Task model implementation

In order to break down complex tasks into smaller, manageable tasks, I propose applying the WBS (cf. Section 3.3). These smaller tasks are structured in the same way, describing actions to achieve a targeted outcome in a given project context. The WBS follows a recursive rule allowing tasks to be reduced to an indefinitely small size. The granularity of each task depends on factors such as the individual assessment of uncertainty level or perception of the respective decision maker. It is the subjective judgement through expertise, capability and perception of uncertainty that determines how a task is assessed, structured and executed. The breakdown from project-(macro-) to task-(micro-) level makes it possible to associate performance to individual tasks and make them as measurable and objective as possible (Blindenbach-Driessen et al., 2010). All these individual tasks are linked and added up to the overarching task. They are interdependent in that e.g. the outcome of a task determines the input of one or several other tasks.

In case of a high level of uncertainty, it is rather impossible to plan ahead and break down necessary tasks. Therefore, I propose to make use of the overall project objectives derived from [START_REF] Griffin | Serial Innovators' processes. How they overcome barriers to creating radical innovations[END_REF]. Based on the investigation of serial innovator behavior, these objectives provide non-linear orientation support throughout the project. They help to consider the overarching project vision while flexibly specifying, adjusting, or rejecting tasks. I adapted and added Griffin's objectives with regard to the corporate context (Gebhardt et al. 2018) and classified them into desirability, feasibility, and viability according to [START_REF] Ries | The lean startup. How today´s entrepreneurs use continuous innovation to create radically successful businesses[END_REF] Desirability verifies whether the project solves the actual need of the user or customer ("Does it help?"). Feasibility verifies whether the project intention is implementable based on operational capabilities ("Does it work?"). Finally, viability focuses on the sustainable value of the project intention e.g. profitability, customer's willingness to pay ("Does it sell? Does it scale?").

Thus, breaking down tasks helps to reduce structural complexity and divide and conquer tasks. It therefore makes it possible to decouple uncertainties by e.g. isolating the most critical aspects of uncertainty in individual tasks according to naviProM-Task. In order to not only plan, but also analyze a project in retrospective, I propose to zoom in single tasks by systematically documenting the individual task elements as shown in Table 8-1: Table 8-1

: naviProM-Task element analysis

The columns of this table indicate the project phase, the task ID, task name for identification as well as the task elements input, targeted outcome, action, the outcome and the outcome evaluation (OE) respectively. This table shall be filled as follows:

 Define task name and ID in order to identify the task to be carried out.  Specify the task inputs, and the targeted outcome.  Specify the action.  Describe the outcome and evaluate its value.

This documentation provides an overall view, which makes it possible to quickly capture individual task content. Each task outcome serves as input for the upstream task. For instance, the outcome of task 1 (specified customer) serves as

52

the input for task 1.1. This automatically makes it possible to show task interdependencies.

9 naviProM-Grid: Task Classification by Uncertainty

naviProM-Grid definition

Following on from RQ2 (Section 6.2), the proposed task model (Section 1) in combination with the uncertainty definition (Section 4.4) leads to the following question: How does uncertainty in a particular task's input, targeted outcome, action, context and stakeholders has an impact on the execution and management of this task? In order to reduce complexity and increase focus, I investigate the relationship between the task's core elements targeted outcome and action, first. I start from two fundamental hypotheses to develop the relationship between uncertainty in a task's targeted outcome and the uncertainty in a task's action:

1) Uncertainty means a lack of knowledge and creates ambiguity for decision makers (i.e. Spencer 1962, see Section 4.1). 2) Decision makers therefore strive to mitigate uncertainties and to reduce complexity to be comfortable in making decisions (i.e. [START_REF] Mu | Effect of risk management strategy on NPD performance[END_REF][START_REF] Ward | Transforming project risk management into project uncertainty management[END_REF][START_REF] Atkinson | Fundamental uncertainties in projects and the scope of project management[END_REF], see Section 4.3). To follow Ashby's law of requisite variety (1957), I propose the naviProM-Grid model. It spans over two axes representing the uncertainty of the targeted outcome with respect to the expected input and the context (UO), as well as the uncertainty of the action based on the expected input and the context (UA) as depicted in Figure 9-1. The two axes represent these two types of uncertainty, which shall both be binary (+/-for high/low) for simplicity. The model therefore differentiates between the following four combinations of uncertainty: high uncertainty in the targeted outcome as well as the action (+/+), high uncertainty in the targeted outcome only (+/-), high uncertainty in the action (-/+), and low uncertainty in both the targeted outcome and the action (-/-).

Reducing uncertainty means adopting an execution strategy that is appropriate for the given uncertainty combination. Based on Kolb's experiential decision model [START_REF] Kolb | Experiential Learning. Experience As The Source Of Learning And Development[END_REF] differentiating between active and reflective mode (inner yaxis) as well as between abstract and concrete mode (inner x-axis), I assigned the four fundamental task execution strategies depending on the given uncertainty combination: Execute, Plan, Iterate, and Experiment.

54

Figure 9-1: naviProM-Grid (Gebhardt et al. 2018;Gebhardt et al. 2019a)

Mapping tasks to naviProM-Grid

High uncertainty in both dimensions (UO, UA) calls for adopting an execution strategy that applies experimentation when executing this task. Thereby, the experiential learning model of [START_REF] Kolb | Experiential Learning. Experience As The Source Of Learning And Development[END_REF] states that project teams learn through "the process whereby knowledge is created through the transformation of experience", which is assumed to pass through the four stages of having an insight, synthesizing ideas, derive corresponding hypotheses, and test them based on prototypes. Experimentation means focusing on gaining insights by exploring and gaining a deep understanding of the underlying requirements, the scope and the context by analyzing the behavior of the potential user or customer behavior (reflective, abstract mode). Making use of observation or feedback makes it possible to uncover latent needs. New ideas can be synthesized (active, abstract mode) and corresponding hypotheses derived and isolated. Exploring these ideas by building prototypes (active, concrete mode) enables the hypotheses to be tested (reflective, concrete mode). A consequently forced frequent refinement and sharpen of the problem statement indicates learning progress. Together, these 55 steps form one experiential learning cycle, which means to fluidly move back and forth between the concrete and abstract perspectives as well as between the reflective and active modes. This cycle can be repeated multiple times until the project team is able to eliminate uncertainty regarding the targeted outcome or the action and feels comfortable moving to a more execution-oriented approach. The lack of value creation makes a mode change indispensable. Order, starting point and time spent in each mode do not follow an established standard [START_REF] Beckman | Innovation as a Learning Process. Embedding Design Thinking[END_REF]. With these preconditions, the project team shall apply human-centered and learning-oriented methods, e.g. Design Thinking [START_REF] Lockwood | Design thinking. Integrating innovation, customer experience and brand value[END_REF], creativity workshops, fast and extensive knowledge building. The outcome focus is on rapid collective learning rather than on tangible, clearly specified artifacts [START_REF] Thomke | Experimentation matters. Unlocking the potential of new technologies for innovation[END_REF]. The high levels of uncertainty levels in the targeted outcome and action can be embraced more easily and thereby lead to significant uncertainty reduction. Therefore, this approach is of high relevance in the context of radical innovation. Lacking tangible, value adding artifacts explains why this not an universal approach. Experimentation is not based on key performance indicators, but rather focused on a rapid learning progress, which makes it difficult to measure and evaluate the performance of a project team.

Established performance evaluations and an organizational culture, focused on quantifiable progress and rapid delivery or factors such as time or budget, pressure project managers to neglect or simply overlook knowledge gaps and the need for exploration by experiential learning [START_REF] Perminova | Defining uncertainty in projectsa new perspective[END_REF]. Further, people are subject to errors in judgement and personal biases, sticking to their subjective assessment frame (underestimating uncertainty, wishful thinking and the delusion of predictability). Decision making (e.g. feedback interpretation) requires active, and strict rules of scientific inference and experiment design challenging personal beliefs [START_REF] Kahneman | Variants of uncertainty[END_REF][START_REF] Davis | Roles during innovation ecosystem genesis. A literature review[END_REF][START_REF] Sterman | Learning in and about complex systems[END_REF].

Key players within experimentation are the project team and the potential users or customers. The project manager can assess the success of an experiment (OE) by comparing the targeted outcome with the actually achieved one after executing a task (Table 9-1). 56 Table 9-1: Example: naviProM-Task in experimentation Perceiving high UO and low UA levels is typically characterized by lacking, ambiguous or incomplete requirements meeting well-established processes and methods. In this case, naviProM-Grid recommends making use of iteration strategy in order to prevent any failure to capture the correct requirements by applying "business-as-usual" to yet unknown needs (unknown knowns or unknown unknowns). Mitigating uncertainty based on iterations follows an "express test cycle", but still complete cycles. This way, a project manager can adopt a learning strategy on the requirement side, remaining open to evolving toward the targeted outcome. Complete iterations relate to switching between active, concrete mode and active, reflective mode, running through a cycle of need specification (update, improvement), elaboration (design, development), and verification/ validation. A properly executed verification/validation step through rapid and continuous consumer or user feedback is important in order to incrementally sharpen or enrich the targeted outcome and make sure the outcome complies with it (see Table 9-2) [START_REF] Cooper | Stage-gate systems. A new tool for managing new products[END_REF]). As a result of the growing understanding, project changes are inevitable, which makes adaptability to change a central characteristic of iteration [START_REF] Mcmanus | A Framework for Understanding Uncertainty and its Mitigation and Exploitation in Complex Systems[END_REF][START_REF] Heck | Iteration-based Performance Measurement in the Fuzzy Front End of PDPs[END_REF]Weck et al. 2007). In contrast to experimentation, learning is restricted by the roughly defined action. Useful agile methods are for instance Scrum, Kanban, DSDM, or the Spiral Model. Like experimentation, iteration is focused on learning, as it is difficult to measure and evaluate project team performance. Joint prioritization of features that should be considered, validated specifications by the user, or rapid reported learning cycles, indicate the learning progress regarding to the targeted outcome. In this case, project manager, users and/or customers are key players close to the project team. Table 9-2: Example: naviProM-Task in iteration Low UO meeting high UA calls for a planning strategy that breaks down the task into further hierarchical tasks to prioritize and clearly separate tasks with uncertain actions from certain ones (see Table 9-3). Thus, a task's outcome includes the sum of all derived subtask outcomes. Typically characterized by a huge number of requirements, sensitive simulation, structure and coordination are required to derive appropriate actions. In order to embrace uncertainty consciously and quantitatively, each task is typically associated with measurable risk indicators, as well as best possible estimations for efforts, durations, and other relevant metrics (e.g. time, budget, quality). It follows a linear, sequential, and relatively predictable approach, in which the planning action takes place upstream and isolated (abstract mode) from the downstream execution (concrete mode). The learning process can therefore be reduced to the active mode: the project team abstracts patterns from the available information base (abstract mode) to synthesize a plan for the further execution (concrete mode). Thereby, the main target is to stick to the plan; an adaptation to changing conditions is not intended [START_REF] Carvalho | Project management and its effects on project success: Cross-country and cross-industry comparisons[END_REF]. Any classic project planning method, such as V-Model, Stage-Gate [START_REF] Cooper | Stage-gate systems. A new tool for managing new products[END_REF]), as well as Waterfall are applicable here.

The manager and the project team play key roles. Historical data as well as established and proven assessment frameworks serve as input as an information basis. This basis is used to evaluate whether the task results in a satisfying outcome or whether the team gets bogged down in details or wastes time and effort adjusting the plan (unsatisfying outcome). Table 9-3: Example: naviProM-Task in plan Assessing low uncertainty levels in both UO and UA provides comfortable conditions in which the necessary knowledge is provided to make founded decisions. When no further learning or planning is needed, a purely executionoriented strategy is recommended in order to achieve rapid project progress. Projects that have all their tasks in this area do not contain any innovative elements. This execution-oriented strategy is concentrated on active and concrete mode. Each task has clearly defined inputs with respect to the targeted outcome, and the way the inputs are to be transformed into these targeted outputs is also clear and well known. Routines, processes, and standards provide the necessary assessment framework. Measuring performance is simple, as the targeted solution can be clearly defined, and the actual outcome assessed against it (Table 9-4).

The key players are the operating experts/team members.

Table 9-4: Example: naviProM-Task in execution At this stage, one relies on the project manager (in collaboration with any concerned stakeholders) performing the uncertainty level estimations required to classify each task into the two discrete levels low and high. While this is undoubtedly a limitation, it provides freedom of estimation and decision that is appreciated by project managers and therefore encourages them to use the tool in their daily working practices. This freedom also enables the refinement and specialization of the tool to fit specific project management decision aid expectations.

In order to practically apply naviProM-Grid to the naviProM-Task model as described above, I propose extending the task evaluation table presented in Section 8.2 as shown in Table 9-5.

Table 9-5: naviProM-Task evaluation based on naviProM-Grid In addition to the columns explained in Section 8.2 the table shall be filled as follows:

 Define the task WS so as to identify the task to be carried out.  Decide upon the level of uncertainty (low "-ˮ or high "+") of the targeted outcome with respect to the inputs based on naviProM-Grid. The judgment is a subjective judgment by the project manager based on his experience.  Decide upon the level of uncertainty (low or high) of the specified action with respect to the task's inputs. This judgement is a subjective judgement by the project manager.  Define the task execution mode according to the classification recommended by naviProM-Grid (R).  Evaluate the actual (A) used classification related to the recommended (R) classification.  Evaluate the outcome based on the level of outcome satisfaction.  A task can be broken down into smaller tasks based on their targeted outcome, whereas task IDs are coded with subordinate numbers.

The naviProM-Grid provides the necessary basis for relating the proposed naviProM-Task (Section 1) to uncertainty. It makes it possible to systematically assess uncertainty in task's elements for the targeted outcome (UO) as well as action (UO) and recommends task execution strategies. Uncertainty regarding the context has not been covered so far and will be elaborated in Section 1. So far, the proposed naviProM tool set includes the naviProM-Task considering uncertainty as a basis for to classifying and executing tasks based on naviProM-Grid (RQ2) capturing UA and UO. In order to also fulfill RQ3, we still have to consider the task's dependency on its context.

In our hyper-connected economy and society, the context has become highly complex. Following system theory, tasks constitute an integral part of projects. Their complexity requires flexible adaptation of methods and tools to changing or differing contexts (e.g. to a specific branch, company, or product), [START_REF] Skalak | Defining a Product Development Methodology with Concurrent Engineering for Small Manufacturing Companies[END_REF][START_REF] Maffin | Engineering Design Models: Context, theory and practice[END_REF]. Project uncertainty frameworks are still rare and not necessarily universal [START_REF] Saunders | Mapping the multi-faceted. Determinants of uncertainty in safety-critical projects[END_REF][START_REF] Shenhar | Reinventing Project Management. The Diamond Approach To Successful Growth And Innovation[END_REF][START_REF] Vidal | Understanding project complexity: implications on project management[END_REF][START_REF] Xia | Complexity of information systems development projects: conceptualization and measurement development[END_REF][START_REF] Maylor | Managerial Complexity in Project-Based Operations: A Grounded Model and Its Implications for Practice[END_REF]). In the design project and process context, previous works such as [START_REF] Gheorghe | Fuzzy Multicriteria Decision Aid Method for Conceptual Design[END_REF] and [START_REF] Roy | Evolutionary multi-objective design optimisation with real life uncertainty and constraints[END_REF] treat design parameter uncertainty using fuzzy and stochastic methods, respectively, without however investigating downstream execution and management of tasks. The existing uncertainty frameworks on a global level cover the relationship between complexity and context insufficiently. This made me look for alternative framework approaches. Due to the fact, that complexity frameworks (see Section 3.1) also have to involve context (environment) and uncertainty, I tried to better grasp the sources of complexity and context. Established context models such as the Hales and Gooch scheme (2004) (see Figure 10-1) are subject to increasing critique based on their high abstraction of context factors. They do not take any direct or indirect influence factors into account. Also, they provide limited support in context-specific application on projects. These macro schemes require "augmenting and tailoring" [START_REF] Gericke | Understanding the context of product development[END_REF]. 62 (2019) also capture system uncertainty, integrating micro and macro levels derived from an extensive literature analysis in product development and design management, project management, general management, organization theory, and psychology. However, these are theoretical non-validated design concepts and vulnerable to subjective biases. In particular they are lacking practicality due to their high number of factors that have to be evaluated with regard to measurability, dynamics, interdependencies as well as relevance [START_REF] Gericke | Understanding the context of product development[END_REF] or their individual frequency of change throughout the project [START_REF] Wilmsen | A context-model for adapting design processes and methods[END_REF]. [START_REF] Shenhar | Reinventing Project Management. The Diamond Approach To Successful Growth And Innovation[END_REF] and [START_REF] Rezende | Revisiting project complexity: a new dimension and framework[END_REF] focus on project complexity, while [START_REF] Rosenberger | Context-awareness in industrial applications: definition, classification and use case[END_REF] propose a context classification framework for context-aware design of industrial applications, though not taking into account the relationship of context to the design project and process.

These frameworks constitute uncertainty and complexity as central and influencing elements of context. I, therefore, postulate that frameworks capturing project's uncertainty or complexity, integrate both project internal (micro level) complexity and/ or uncertainty and a project's environmental (macro level) complexity and/or uncertainty. This would address the still lacking requirement of practicability. Hence, an integrated model considers the fact, that a project has to be actively adapted to its context, and that the project affects the context [START_REF] Gericke | Understanding the context of product development[END_REF].

Recent scientific frameworks considering uncertainty or complexity are for instance, [START_REF] Breitschuh | Scaling agile practices on different time scopes for complex problem solving[END_REF]. The authors developed the Entropy-Compass in order to capture project complexity as a dynamic system property (see Figure 10-2). Therefore, the authors combine the established schemes of [START_REF] Hales | Managing Engineering Design[END_REF] and the complexity dimensions of VUCA (Volatility, Uncertainty, 63 Complexity and Ambiguity) as entropy drivers to capture system complexity. The integration of the Cynefin model [START_REF] Snowden | Complex acts of knowing: paradox and descriptive selfawareness[END_REF], which differentiates context, makes it possible to capture complexity on an operational level. Thus, the Entropy Compass integrates both complexity of the micro and the macro level and guides users to the appropriate methods and tools. 2019) propose a complexity framework for capturing project complexity (Figure 10-3). It is based on a systematic and extensive literature research related to "project complexity". At the top level, the framework differentiates between structural complexity, uncertainty, pace, novelty, dynamic social-political, and institutional dimension, which were further specified in ten subdimensions. Despite a rating scale, the framework is not a measurement tool, but is designed to enrich discussions about a project's complexity throughout its life cycle. 64 The presented frameworks all refer to the three constructs of context, complexity and uncertainty, but based on different perspectives. First, established context frameworks refer to uncertainty and complexity as central factors influencing context. At the same time complexity models such as Rezende and Blackwell define uncertainty as well as context (in particular, the social-political dimension) as dimensions of project complexity. Third, Saunders, by contrast, constitutes context defined as environment and complexity as two perspectives of uncertainty. The Entropy-Compass integrates the dynamics of system context by making use of the Hales and Gooch scheme (environment) and perceives uncertainty as one factor of many by making use of the Cynefin model (complex and structural complexity) and entropy (availability of knowledge).

Especially for the research field of product development, various authors have argued that uncertainty is at the core of product development complexity (e.g. [START_REF] Meboldt | The dilemma of managing iterations in time-to-market development processes[END_REF] and traced this back to a lack of knowledge and definition [START_REF] Albers | Systems Of Objectives In Complex Product Development[END_REF]. At this point, it may be a trivial insight to say that projects differ from one another in terms of sources of complexity. Thus, all these factors are connected. Project complexity can come e.g. from the solution itself as well as from the context factors such as variety or the number of actors involved. The underlying idea is that an IP task's uncertainty is largely influenced by the project's complexity, which is in turn a major source of context. Context is thereby itself affected by complexity and uncertainty, as is complexity by context and uncertainty. Figure 10-5 depicts this dynamic, (over time) triangular relationship that challenges every single project and ensures that any project and its tasks are never simply the repetition of a previous one, and what is best practice in one project could be the worst practice in another one.

naviProM-Compass approach

In order to assess task uncertainty comprehensively and fulfill RQ3 and RQ4, I decided to capitalize on relevant published frameworks and the existing validated project management knowledge that is contained therein. Such frameworks need to (1) integrate a micro as well as macro level of context, (2) to ensure practicability by (a) quickly and (b) recurrently capturing context, (3) and needs to be applicable to innovation project management and (4) capture the triangular relationship of context, complexity, and uncertainty appropriately. Against this background, I selected the complexity framework by [START_REF] Rezende | Revisiting project complexity: a new dimension and framework[END_REF] and the Uncertainty Kaleidoscope by [START_REF] Saunders | Mapping the multi-faceted. Determinants of uncertainty in safety-critical projects[END_REF] that fulfill my requirements best.

The latter one proposes six fundamental determinants including information (referring to my definition of uncertainty), complexity, and environment (context) as well as time, capability, and individual in order to frame project uncertainty. These determinants are further specified by concrete factors that potentially characterize this dimension, which provide project managers with a better idea of where uncertainty may arise. The entire literature research as well as validation confirms the model's practicability for visualizing the uncertainty landscape as well as better identifying and assessing where uncertainty may arise. The model is, however, adapted to the context of safety-critically projects and is lacks a rating scale.

The complexity framework by [START_REF] Rezende | Revisiting project complexity: a new dimension and framework[END_REF] differentiates between ten dimensions, which the six Kaleidoscope determinants can be mapped to (see Table 10-1). Contrary to the Kaleidoscope, however, it does not provide any concrete examples for each dimension. A high valuable contribution, however, is the metrics this framework associates with each dimension. It consists of both a descriptive and quantitative rating scale allowing to quantify and interpret the contribution of each dimension. The fact, that [START_REF] Rezende | Revisiting project complexity: a new dimension and framework[END_REF] cite the work of [START_REF] Saunders | Conceptualising uncertainty in safety-critical projects: A practitioner perspective[END_REF] is another indicator for the strong relationship between the two frameworks. [START_REF] Breitschuh | Scaling agile practices on different time scopes for complex problem solving[END_REF] cover for instance similar parameters. They do, however, exclude novelty and dynamics from their parameters. By contrast, they consider them indirectly as these parameters are evaluated based on Cynefin, which covers novelty and dynamics (in particular in chaotic). The model is, however, adapted to the context of mechatronic product development projects. It differentiates only three task execution strategies (plan, iterate, hybrid) based on Cynefin, whereas naviProm-Grid differentiates between four strategies, including experimentation.

Building on the triangular relationship model, I therefore mapped complexity dimensions to the six Kaleidoscope determinants, see

Complexity framework

Social-Political

Pace Structural complexity

69

The combined parameter framework was evaluated with experts in numerous interviews. The outcome of these interviews was a streamlined list of parameters visualized in a model that I named naviProM-Compass, as shown in Figure 10-6. It shows the clustering and association of parameters with the metrics proposed in [START_REF] Rezende | Revisiting project complexity: a new dimension and framework[END_REF], as well as additional metrics for those parameters that are not included in the complexity framework.

The cluster to task mapping is as follows: Information covers the parameters Novelty and Ambiguity and maps to UO. Complexity covers the parameters Interdependence and Size/Variety and maps to UA. This confirms the design complexity definition by [START_REF] Lu | Complexity in design of technical systems[END_REF] clearly stating that only design solutions can be complex, and never the design problem itself. The design problem (targeted outcome) can, however, be subject to incomplete or ambiguous information as well as new conditions. UO and UA are the key parameters for task classification with naviProM-Grid, which is why the related context complexity parameters indicate the "North" on the compass. The other four overarching clusters Capability, Environment, Time, and Individual characterize the context in which the task is intrinsically embedded and therefore influence both UO and UA. For reasons of practicality, these clusters are further broken down into twelve dimensions each associated with a quantitative (1-4) and descriptive metric:

1. As mentioned, the Information cluster includes two parameters.

Ambiguity comprises the available information and knowledge base in a range of 1-known to 4-unknown (e.g. ill-defined requirements, or absence of information about customer or requirements). Institutional characterizes all constraints, e.g. changing policies and regulations, and ranges from free to very constrained. 5. The Time cluster is summarized in Speed, Criticality, and Dynamic. The Speed parameter is defined as tempo e.g. affected by stringent deadlines and a sense of urgency. Criticality is characterized by strategic relevance. Dynamic defines how the project and its tasks are evolving over time as well as task environment changes along a project's life cycle. 6. Individual describes the individual perception and handling of uncertainty, personal interests, attitudes, values, bias, risk-taking, venturesome, etc.

The verification of context parameters was carried out in the form of a quantitative questionnaire using the online survey tool Qualtrics (see appendix). The sample includes 48 responses after eliminating (15) incomplete questionnaires. The 48 participants have project management experience in different sectors, the majority in life science (10.42%). The questionnaire aimed at validating and further identifying factors influencing UO and UA. It consisted of nine questions referring to industry/sector occupation, project type, and years of project management experience, as well as the most relevant factors influencing UO and UA. At the end of each of these six questions, I added a qualitative question to get input about further factors the respondents considered relevant.

The average number of 11.4 years' experience (range 2-25 years) in project management guarantees for the value we can get from the respondents' answers. They were asked how these parameters applied to their projects and to add any parameters they felt were missing. I measured the completeness ratio based on participants who did not select the option "other". The relevance of complexity parameters leading to solution uncertainty (87%) and information parameters leading to need uncertainty (80%) respectively were confirmed, since only 13% and 20% suggested other parameters (in addition). For the context parameters, the relevance ratings were balanced across all the other parameters; only 14% suggested additional parameters. I interpret this as a confirmation of the practical relevance of my framework. I clearly highlight here that project stakeholders with direct or indirect influence on the project are an outstanding element of a project's context that is not captured by naviProM-Compass in Figure 10-6 and will be covered in Section 1.

naviProM-Compass integration

Following the need to consider context systematically in order to identify a task's UO and UA completely, I propose to add the naviProM-Compass to the naviProM tool set. The influence of each of the context parameters suggested by the Compass depends on the specific project and task. For instance, Speed is probably of particular relevance for projects with a defined deadline or high dependency on seasonal variants, while it is of lower relevance for others. This requires the introduction of a weight factor for each context parameter. To take this into account appropriately I decided to introduce a weight factor for each parameter.

The naviProM application strategy is as follows:

1. At the beginning of the project, decide for the weighting factor of each parameter based on their relevance (a weight factor of 0 excludes a parameter from investigation and reduces the naviProM-Compass). Regarding the proposed task model, the naviProM-Compass provides the necessary basis for naviProM-Grid by capturing and accumulating a task's influencing context, its impact with regard to UO and UA, and the impact of its constituting parameters. It makes it possible to systematically detect where uncertainty may arise. Besides, it provides complementary background information for naviProM-Grid application for deriving task execution strategies on how to reduce, break down, or exclude uncertainty.

Social Network Analysis (SNA) principles

A project team that is embedded in an organizational, and therefore social and political, context can be modelled as a network graph that has a complexity measure. Networks can be examined in terms of their structure and composition [START_REF] Phelps | A Longitudinal Study of the Influence of Alliance Network Structure and Composition on Firm Exploratory Innovation[END_REF]Wasserman andFaust 1989, 2012). The former provides a quantitative and/or graphical representation of the interconnections between the network nodes (i.e., the "network syntax"). The network composition describes the characteristics of the nodes and their links (edges, ties) and quantifies the diversity of those attributes (i.e., the "network semantics"). [START_REF] Parraguez | A Networked Perspective On The Engineering Design Process: At The InterSection Of Process And Organisation Architectures[END_REF] provides an outstanding overview of network metrics for structure and composition. For structural metrics, size, density and centralization are key on network level. For nodes and edges, different centrality measures convey measurable information related to the connectivity of particular nodes with the rest of the network or parts of it. As for quantifying composition, metrics such as the Index of Qualitative Variation (IQV) provide measures of e.g. network heterogeneity.

Representing stakeholders and their relationships within a project or process with such network graphs and using related metrics opens up the opportunity for the applying of the huge body of network graph analysis algorithms to analyzing of social networks. This particular type of graph analysis methods and applications has given rise to the scientific field of Social Network Analysis (SNA) (Wasserman andFaust 1989, 2012). SNA methods are based on an extensive yet flexible set of metrics that can be applied on multiple levels of analysis, both of purely social networks, and of projects, processes, products, and services (e.g. [START_REF] Collins | Evaluating product development systems using network analysis[END_REF][START_REF] Collins | Analyzing Product Development Task Networks to Examine Organizational Change[END_REF][START_REF] Sosa | Identifying Modular and Integrative Systems and Their Impact on Design Team Interactions[END_REF]. In a particular project context, such analyses have a key role in predicting and understanding interdependencies and influences both on and from the project to the task level [START_REF] Sosa | Realizing the Need for Rework: From Task Interdependence to Social Networks[END_REF].

Besides network theory, role theory helps to better characterize nodes (stakeholders) based on their specific role, expectation, norm, or skill profile. In the context of innovation projects, research emphasizes the single role of the champion or entrepreneur promoting the project from idea to implementation [START_REF] Tushman | Organizing for Innovation[END_REF][START_REF] Howell | Champions of Technological Innovation[END_REF]Dedehayir et al. 2016) or the sponsor providing support based on commitment or resources. Under conditions of uncertainty, entrepreneurs or innovation teams do not usually have the necessary competences to drive an idea from exploration and testing to production and market launch of a final solution [START_REF] Kelley | Intra-organizational networking for innovation-based corporate entrepreneurship[END_REF]). Instead, they must expand their network by involving e.g. external or internal experts to get access to complementary assets [START_REF] Greve | Social Networks and Entrepreneurship[END_REF][START_REF] Teece | Profiting from technological innovation. Implications for integration, collaboration, licensing and public policy[END_REF]). Hence, [START_REF] Roth | Stakeholder integration in service innovationan exploratory case study in the healthcare industry[END_REF] emphasize the role of top management, experts and customers or buyers. Others emphasize the relevance of customer-related roles [START_REF] Nyström | Actor roles and role patterns influencing innovation in living labs[END_REF], or cluster roles into different ecosystems (Dedehayir et al. 2016). Another perspective is the promoter model, which is not based on single roles, but rather on the source of power. The power promotor has the resources, competence, and hierarchical power to make decisions (similar to gatekeeper or sponsor). An expert promotor or technology promoter [START_REF] Hauschildt | Teamwork for innovation -the 'troika' of promotors[END_REF]) provides technical expertise. The process promoter has organizational know-how and intra-organizational networks, while the relationships promoter was further added, providing strong internal and external (e.g. customers, suppliers) relations [START_REF] Gemünden | Role Models for Radical Innovations in Times of Open Innovation[END_REF]. In this context, research refers to the role of the gatekeeper, who e.g. channels information and communications, or sets decision criteria [START_REF] Markham | The Valley of Death as Context for Role Theory in Product Innovation[END_REF]Dedehayir et al. 2016).

Roles, such as networks, are temporary, which means that they may change [START_REF] Nyström | Actor roles and role patterns influencing innovation in living labs[END_REF]) and have different relevance for specific tasks during a project life cycle. [START_REF] Gurtner | From roles to skillskey persons in the innovation process[END_REF] It is even more important considering the individual relationships between these roles and project's tasks. IPs have to be formally integrated into the permanent organization to which innovative solutions generally do not fit. Thus, well-established practices and processes must be adjusted or eliminated, leading to active and passive organizational resistance. Furthermore, under conditions of high uncertainty, when there is no formal organizational acceptance or affiliation of an idea, dedicated resources are limited. Teams have to create value related to their vision [START_REF] Andersen | Do project managers have different perspectives on project management[END_REF]) in order to build a network of supporters that will lead them in the targeted direction (e.g. with their network, expertise, resources) [START_REF] Kelley | Intra-organizational networking for innovation-based corporate entrepreneurship[END_REF][START_REF] Greve | Social Networks and Entrepreneurship[END_REF]. It is even more important to not isolate the project and rather be aware of and understand the established structures, processes, or habits that constitute the overall system [START_REF] Kelley | Intra-organizational networking for innovation-based corporate entrepreneurship[END_REF]). Hence, it is not the sum of existing relevant actors that makes it possible to exploit network or actor potential, but their facilitation and orchestration [START_REF] Goduscheit | Innovation promoters -A multiple case study[END_REF][START_REF] Provan | Modes of Network Governance: Structure, Management, and Effectiveness[END_REF]. In this case, people do not fulfil their formal functions or roles, but act on the basis of personal conviction, interest and motivation. They have a positive attitude towards the project. Besides this attitude, the influence of stakeholders is relevant. The project's integration into established organizational structures makes the success dependent on dedicated and committed resources and therefore on individual stakeholders' attitudes and influences [START_REF] Hoang | Network-based Research in Entrepreneurship. A Decade in Review[END_REF]. However, people with a negative attitude can have a negative influence on the project, e.g. through resistance, fear or conflict.

naviProM-Net modelling element and approach

Following the demand to capture stakeholders and their impact on the task's uncertainty and the task's execution strategy (RQ5, RQ7), I propose naviProM-Net to complement naviProM-Task and naviProM-Grid with the key ideas from Social Network Analysis (SNA).

With regard to addressing whether and how uncertainty in tasks shall be performed and managed, I propose expanding the project manager view, formalizing a stakeholder's impact on each task addressing RQ10. Hence, it is assumed that the stakeholder network influences all the task model's elements, i.e., targeted outcome, action, and context. As specifically informal roles strongly influence the development of tasks [START_REF] Markham | The Valley of Death as Context for Role Theory in Product Innovation[END_REF], I focus on informal relations without explicitly differentiating hierarchy network relations.

Derived from scientific findings in role and network theory [START_REF] Markham | The Valley of Death as Context for Role Theory in Product Innovation[END_REF]Dedehayir et al. 2016), I sharpened major roles with respect to the task perspective and IPs in the corporate context. There are two central roles that determine task-related uncertainty, particularly with regard to the targeted outcome:

1. The user or customer, who potentially uses or buys the final solution, as well as the early adopter who embraces new solutions before other market players (Rogers 2010). 2. The sponsor or principle, who commissioned the task, and who provides resources that are not formally implemented as well as project support and protection in demonstrating task feasibility [START_REF] Tighe | From experience. Securing sponsors and funding for new product development projects -The human side of enterprise[END_REF]).

These roles determine the requirements and shape the targeted outcome of a task. To specify, capture, transfer and operationalize this targeted outcome in concrete actions, further roles are critical for tasks:

3. The core team that drives the project. 4. Functional experts who have complementary and required expertise to specify the targeted outcome and fulfil a task. 5. Coaches may support on the methodical level.

In the corporate context, relationship management between the temporary task and the existing organization is of high relevance. To overcome these difficulties, another role is critical: 6. Gatekeepers can provide access to the required resources on the organizational level. As the influence and attitude of actors may vary, the model further captures positive, negative, and neutral attitude as well as low, medium, and high influence (Figure 11-3). The relationship can be undirected, unidirectional, and bidirectional. The core team obviously has the highest and ideally positive impact on the task progress, however, the idea is to visualize the team as a whole in order to capture all the potential project influences coming from stakeholders. Figure 11-4 shows a sample network providing an example of how the proposed visualizing elements can be used and interpreted. In this network, the team is directly linked to one gatekeeper ("G"-node), one sponsor ("S"-node), two internal as well as one external functional ("F"-node, red dotted line) experts. These direct relations are considered in the investigation of personnel or egocentric networks. However, core teams may not have all the required network contacts in their direct network. As depicted by the three external customers ("B"black node, red-dotted line), actors can also be indirectly linked through a chain of relations which may hamper access to required resources. The gatekeeper is of particular interest, since he has the only access to the external market, i.e., the customer. This important relationship with the customer is represented by a fat double-sided arrow. The gatekeeper's negative attitude towards the project (indicated by the white-color in the node) could indicate potential obstacles (e.g. suppression of knowledge flow) and refers to special attention. In other words, whether the massively influencing stakeholder (here the stakeholder) is using its influence to support, hamper or even stop the task is affected by its attitude towards the task. The functional experts as well as the sponsor have a neutral attitude toward the project (grey-colored nodes) and have low (dotted line) to medium influence (thin line) on the project. In order to apply the naviProM-Net appropriately, I propose to capture all directly and indirectly related actors to the core team in a first step. Second, the attitude towards the project must be assessed. Third, the influence and the direction of this has to be determined. The size (measured by the number of nodes; here: 8) and diversity (number of different nodes; here: 6) of networks vary and typically increase during a project (Dedehayir et al. 2016). Thus, I further propose capturing and assessing all relevant actors and relations at the beginning of a project and adjusting these at the beginning of each project phase. This makes it possible to capture dynamics, to analyze the stakeholder influence in retrospective, and derive necessary strategies in order to e.g. close network gaps, win lacking sponsors or convince critics.

Based on its visualization elements, naviProM-Net makes it possible to systematically capture relevant project actors and their relationships to the project in order to detect critical or missing nodes or relationships. The key advantage of encoding these roles and their relationships in the form of a connected graph is to make available the huge set of graph analysis algorithms to understand stakeholder influences in order to apply this knowledge to task planning and analysis as well as strategy development. For example, a node's centrality is a measure of the corresponding stakeholder's capacity for reaching other stakeholders. Stakeholders with high centrality have the potential to fulfill the role of gatekeepers.

With regard to the proposed task model, the integration of the SNA makes it possible to complement the naviProM-Compass in order to integrally capture a project's context. The actual application of naviProM-Net at task level follows in Section 1.

naviProM-Flow: Visual Project

Planning & Analysis

Gaps of current project visualization approaches

Although there are numerous methods and tool-supported techniques enabling planners to visualize the structural elements of a project (work packages and tasks), there are only very few that are used widely and universally. Among these, Gantt, PERT (Program Evaluation and Review Technique), and DSM (Design Structure Matrices) charts are the most outstanding ones. None of them, however, takes into account any kind of uncertainty in terms of e.g. time, resources (RQ2), and context (RQ3). Based on studies such as [START_REF] White | Current practice in project managementan empirical study[END_REF], this represents a huge gap as project managers increasingly report that in order to come up with realistic schedules, they need to take account of uncertainties in their planning. More often, and in increasingly many domains, planners have to deal with inexact knowledge about future activities and their interdependencies. While the aspect of temporal uncertainties has been investigated in some research approaches such as PlanningLines [START_REF] Biffl | An empirical investigation on the visualization of temporal uncertainties in software engineering project planning[END_REF], uncertainties coming from specifications, understanding and clarity of targeted results and/or the required actions that lead to these have been much less investigated. They cannot be included in current project management and visualization tools such as Microsoft Project.

Another shortcoming of current project planning and visualization methods and tools is their inability to include information flows and relationships between tasks (RQ6, RQ8) and the stakeholders influencing these tasks (RQ5, RQ7). The only way of including stakeholders in the project plan in a Gantt plan is to assign human resources from a resource pool to tasks. In order to complement this assignment with indispensable information about the assigned resources' roles, project managers typically use a RASIC matrix to clearly specify who is responsible, accountable (approving), supporting, informed, consulted. While this complementary information includes some aspect of relationship, it fails to capture influences both among the resources and between resources and tasks, as well as whether these influences have a positive, neutral, or negative impact on the task.

Probably the biggest gap of these approaches is, however, that they only represent what project managers plan or expect to happen, typically also with few if any updates on their insights and views. There is no representation of the actual situation in the project, and consequently no intrinsic comparison of the latter against the planned/desired situation. Also, due to the lack of a systemic overview of the actual project happenings, relationships and interactions process, there is no learning from patterns that appear. The rationale and history of decisions made and the way they contributed to the outcomes is typically lost and therefore not directly usable for future projects. This represents a major gap in terms of knowledge management for project managers, in particular for innovation and design projects [START_REF] Roucoules | Engineering design memory for design rationale and change management toward innovation[END_REF].

Our objective here is to propose a new project planning and visualization approach that tries to fill some of these gaps by providing practicable add-ons to common existing tools. In order to achieve this, I propose a visual project modelling language that makes it possible to integrate naviProM-Task and naviProM-Grid for including task and context uncertainty in planning, as well as naviProM-Net for including stakeholder influences and uncertainty.

naviProM-Flow project visualization elements

I integrated the naviProM tool set elements presented so far in naviProM-Flow, making it possible to specify and visualize tasks as well as their relationships from micro to macro (project) level. The naviProM task model as well as the WBS concept provide the basis for this. The WBS enables project managers to break down an overarching task into smaller tasks, which are interlinked through their individual input and outcome flows (RQ6). They can merge into different primary work streams, such as the customer development work stream (CDW) or the solution development work stream (SDW). Under conditions of high uncertainty, major work packages function as generic tasks and optional reference points. The input of a task determines which naviProM approach constitutes the most efficient approach under the respective task conditions and determines the expected outcome (e.g. new insight, see Section 10). Independent of the chosen approach, the satisfaction in the task outcome can be defined as either satisfying, unsatisfying, stopped or unknown at time of documentation (Figure 12-1). Inciting project managers and their teams to define their objectives and the definitions of success and failure from project-(macro-) to task-(micro-) level is important for rendering performance assessment as measurable and objective as possible (Blindenbach-Driessen et al. 2010).

Building on Section 11, involved stakeholders are included in each task in terms of their level of influence and their attitude to the task (RQ5). By contrast to edges visualizing the influence level in the SNA, "+", "-", "~"-symbols are used in the project flow to simplify the display. For visualizing tasks, their classifications, outcome evaluations and relationships with other tasks, the symbols specified in Figure 12-1 shall be used.

Established tools such as Gantt provide a simple illustration of an overarching work stream as a black box ignoring the dynamics within a work stream. naviProM-Flow supports the transparent merging of tasks into work streams, as well as zooming into tasks in order to visualize derived tasks and their interdependencies along a task's life cycle and changing context conditions (RQ8). These are important functionalities for capturing and visualizing the dynamically evolving project structure on different abstraction levels (see Part III). Some of the twelve mentioned projects had to be stopped or were paused. From the beginning of the second year, I therefore directed my focus on four active projects, three of which were part of the internal entrepreneurship program (see also Figure 13-2). As depicted by the different workstreams in Figure 13-1, I chose different methods to apply naviProM: I observed and interviewed the teams (grey work stream). Further, I observed, interviewed and applied naviProM in retrospect (light blue colored workstream). Finally, I applied naviProM for prospective planning (dark blue colored workstream). In order to capture the naviProM-relevant aspects of every project, I interviewed team members, joined and actively participated in team meetings as well as central workshops. To further validate generated insights in the four focused IPs, I continuously asked for feedback of IPs I had joined in my first year. For confidentiality reasons, project specific details cannot be disclosed here. However, for the purpose of demonstrating the research design and its validation, such project specifics are actually not required. I will therefore generalize project insights.

14 Project Smart -retrospective analysis

Project introduction

In this section, I present the key insights I gained about the analytical power of naviProM from the project I will subsequently call Smart. This IP has been performed in a business area having no direct access to customers. In the beginning (phase 1 and 2), the project team consisted out of four employees. All of them worked full time on the project. From phase 3, the team grew to eleven employees that work between 50-100% on the project. All of them are information technology (IT) experts located at the same site. Their mission is to develop a new business model for a smart quality product-service system for global use. Throughout the project, the prototype of the service-enabling technical device that they have been continuously improving and extending has reached technology readiness level (TRL) 6 [START_REF] Mankins | Technology readiness levels. White Paper, Advanced Concepts Office[END_REF] after a project period of 1.25 years and is about to be launched on an extended test market (precommercial sale, TRL 7).

Methodology

In order to analyze the Smart project's development progress, naviProM was applied retrospectively to each task of every project phase (see Section 14.3). Together with the project leader and/or team members, with whom I had monthly face-to-face interviews, we identified the primary work streams as well as the key phases within the naviProM-Flow. We then specified the tasks in terms of input, targeted outcome, and action using the symbols specified in Section 0. We performed the uncertainty classification regarding to UO and UA using naviProM-Grid and naviProM-Compass. As the naviProM-Compass was not fully developed at the time of project documentation, the Compass was only partly applied by quantifying Information with regard to UO and Complexity with regard to UA. The complete naviProM-Compass was applied only once and retrospectively, assuming that uncertainty parameter values remained constant on the macro (project) level during each phase. The team confirmed that context conditions were relatively constant. We encoded all these elements using 90 naviProM, assigning a unique numerical identifier to each task in the following generic format: <phase-id.task-id,OE-id>. At the end of each project phase, we evaluated each task's outcome and adjusted task durations. We also identified key stakeholders for each task as well as their attitudes and relationships by using naviProM-Net in order to analyze the organizational context.

naviProM-Flow analysis

Description of the project structure

Throughout the project phases 0 to 4, we applied naviProM to each task and visualized the planning results using the symbols specified in Section 0. Figure 14-1visualizes the project's status as known at the beginning of phase 4. It shows the naviProM-Flow of the three work streams of the Smart project: CDW, SDW, and BDW. It further shows the 4 phases of the project. Phase 1 focused on understanding the problem and solution exploration. Phase 2 concentrated on solution development. Phase 3 focused on pilot solution design, while the future phase 4 will concentrate on the setup for the product implementation. Every task is labeled by a task ID and task name (see Table 14-1 for more details). For the sake of readability, we show the stakeholder dimension only in phases 1 and 2.

In phase 1, tasks focused on desirability and were mainly concentrated on CDW and SDW. The team started structuring its approach by breaking down the task structure understanding (1) in two subtasks: validate problem of version 1 (V1) (1.1) and develop solution V2 (1.2).

The perceived uncertainty regarding the true customer needs in 1.1 made the team use experimentation. Thereby, they involved an external early adopter (E) to define the problem. He showed a strong positive influence (black-colored node). Confronted with a high number of potential approaches, the team ran two separate experiments. One explored potential hardware (HW) solutions (1.1.1), whereas the second investigated potential software (SW) solutions (1.1.2) in a lab set up. Both experiments provided satisfying outcomes ("+") and helped to better understand the scope. These lab tests helped to derive, which additional uncertainties real life conditions would induce. Consequently, the team decided to tackle each uncertainty in a separate experiment. This led to six experiments (1.1.1.1-3, 1.1.2.1-3) each testing different HW and SW prototypes in real life conditions. The ensured intellectual property protection (1.1.3) made it possible to involve external experts in subsequent tasks. Thereby, the team followed an established business process. As shown by "+" (OE) all experiments in phase 1 resulted in new insights (i.e. a satisfying outcome), while the execution (1.1.3) resulted in the needed intellectual property protection.

The task develop solution V2 (1.2) started from an already existing solution. The intent was to develop it iteratively. As soon as the team found out that further 91 iterations would no longer address the most critical assumption as in V1, they paused this task ("!").

In phase 2, tasks were concentrated on feasibility (SDW). The insights generated in phase 1 provided necessary information to outline a prototype for the HW as well as SW development. Therefore, the team decided to split the task structure development (2) into three dependent subtasks, get funding (2.1), develop hardware HW (2.2) and SW solution (2.3). The funding task (2.1) result in satisfying outcome providing the basis for the subsequent tasks 2.2-3. As prior tests were based on initial prototypes, not providing clear specification, the team decided to work iteratively. At this point they also involved external functional experts ("F"-shaped, grey-colored red-dotted node) where needed. Solution development (2.2-3) resulted in satisfying outcomes.

In the ongoing phase 3, the team focused on viability in three separate tasks. To prepare a pre-market/pilot implementation, the team first applied for funding (3.1). The funding provided business sponsorship and the basis to develop the pilot solution (3.2). For the pilot solution, the insights for the HW and SW development gathered in tasks 2.2-3 were pooled. The team decided for iteration as the specifications regarding the set up as well as the development of an overall solution were not clear. In the third task the team resumed working on V2 based on the mitigated uncertainty with respect to V1. Therefore, two experiments were set up (3.3.1-2) that were still ongoing ("?") when documenting this project.

In future phase 4, tasks are planned (4.1-2) aiming at testing the temporary paused solution concept of V2. They shall be approached by iteration, as the team expects continuous learning from the pilot. Thus, at time of project documentation, significant progress was made but there is still uncertainty about the viability of the basic solution V1. Furthermore, there is uncertainty about feasibility and viability of the extended solution V2.

Of particular interest is the variety of experiments in the beginning of the project whereas the iteration strategy becomes dominant in the later phases. This is depicted by the high number of light (X) and dark blue (I) tasks. It indicates that the team addressed the high level of uncertainty early on and in a dedicated as well as agile way. The satisfying outcomes refer to a steep learning curve the team made.

Analysis of the project

Since this project has been successful, and the team made intuitively use of different task execution modes to deal with the uncertainty, I used it to perform an initial practical validation of naviProM. Furthermore, I focused my analysis on phase 1 and 2 by systematically zooming in on every single task. Table 14-1 lists all tasks according to the methodology described in Section 9.2. Following the generic format, I specified task IDs, work stream (WS), task name, input, targeted outcome, UO, action, UA, recommended (R) and actual (A) naviProM classification, the outcome and the outcome evaluation (OE), respectively. UO as well as UA were assessed without considering the context with naviProM-Compass.

Elimination of uncertainty

In phase 1, the team first structured and prioritized the most critical assumptions based on the aligned project proposal (input) in task 1. In this, UO was evaluated as relatively low (2) due to the low assessment of novelty (new target: 2) and ambiguity (roughly defined project proposal: 2). UA, by contrast was evaluated as very high (4) due to a high evaluation of size/variety and interdependence. Thus, naviProM would have recommended planning, the same mode that the team actually applied. Planning implied braking down the task in subtasks. Both SW and HW development (1.2-3) were evaluated as having high UA and UO. This asks for experimentation. The further break down in six subsequent experiments (1.1.1.1-3; 1.1.2.1-3) clearly indicates that an intermediate planning step took place. This was not mentioned during the interviews but confirmed by the project leader. The planning of the six experiments was done intuitively. It was not consciously captured as a task. naviProM makes this task explicit, sets a deliberate decision point and systematically defines concrete next tasks and its proper classification.

The prioritization of most substantial features in task 1 as well as the separation of secondary aspects was necessary (1.2) to ensure a proper experiment design. Besides, the lab set up (2.2-3) before the real-life tests (1.1.1.1-3, 1.1.2.1-3) allowed to stepwise include uncertainty. Table 14-1 shows that UA continuously decreases, whereas UO remains constant as critical aspects (real life application) are addressed one after the other. The decreasing UA and UO values confirm the learning curve of the project. In accordance with naviProM, parallel tasks such as 2.2-3 require different approaches, iteration or execution. If the project team had focused on the most critical uncertainty, it would not have started task 1.2 in phase 1. The team recognized this and paused this task after some time and picked it up in phase 3.

Faster development progress by iteration

In phase 2, the teams started with structuring results of phase 1 in a planning task (2) and derived three subtasks (2.1-3). First, the team applied for funding (2.1). They made use of iteration as the area of sponsorship was clear (UA) whereas the amount and details were not specified (UO). The ensured funding combined with the learning progress in phase 1 enabled the team to reduce UA and to start solution development. Consequently, they were able to select and concentrate development on one HW and one SW solution task (2.2-3). Compliant with the naviProM recommendation, the team was able to switch from experimentation to iteration as in both tasks, specifications were still uncertain (high UO), while UA was satisfyingly reduced. This new mode increased 93 development progress. Thereby, they involved external experts in solution development (2.2-3) which was possible thanks to intellectual property protection achieved in subtask 1.1.3.

Special role of planning

Planning helps teams to prioritize and decide on tasks. This takes place at the beginning of each phase (see e.g. 1, 2, and 3) and as illustrated above after new insights need to be incorporated. According to naviProM, UO needs to be low, whereas UA is high in planning. Prior tasks (see e.g. 1.1.1-3) as well as subsequent tasks (see 2.2) are however evaluated with high UO, which point at the fact that in Structure development-task (2) there was actually high UO.

These planning-tasks based on the decision to temporary neglect UO. This allowed perceiving the project from a global level, considering the overall learning progress from prior tasks. It was based on the decision to derive and subdivide tasks first and deal with uncertainty later. This decision under obviously remaining UO allowed to systematically decide on next tasks in the overall system context, preventing to get lost in individual tasks.

The comparison of applied task approaches based on intuition and recommended ones based on naviProM metrics (excluding context so far) in phase 1 and 2 are in good alignment. They point at the difference to traditional project management breaking down an overarching task into smaller tasks. Following system theory, uncertainty in each task demand for reassessing by consequence, adjusting execution strategy for each task. I interpret these results as a practical valuation of naviProM, which also confirms the high level of uncertainty. Tasks 1.1 and 2.1 constituted exceptions, which both were at the limit to low UO. Whereas for 2.1 the team assessed UO as low and in 1.1 as high meaning for the latter one the conscious decision for iteration and for 2.1 execution. Both tasks will be discussed in more detail in Sections 14.4 and 14.5.

Project context analysis

In order to enrich the analysis based on naviProM-Flow, I applied naviProM-Compass together with the team on the overall project level so as to capture the context uncertainty influencing the project Smart. First of all, we determined a uniform weighting of 1 for all context parameters before evaluating them individually.

The value of UA was 4 and therefore (very) high independently from its context (see Section 14.3.2). This was in particular caused by the high number, size and interdependence of actors, resources and approaches (Complexity). High UO value of 4 was caused by the fact that requirements could not be translated into specification (Ambiguity), and combined with new context (Novelty).

Moreover, the team evaluated the following context areas as further increasing uncertainty parameters as shown in Table 14-2. Time factors (seasonal dependencies). Dynamics was judged to be unstable and disordered, as not only internal, but also market conditions could cause instability. Individual factors due to diverse uncertainty perception. While criticality and capability were assessed as low, the team decided to systematically reduce political and social factors, as both the team spirit and commitment was high, and the project sponsor was close to the team. Table 14-2: naviProM-Compass evaluation -Project Smart Thus, context value of 2.25 is low for both UO and UA, yet closely at the threshold to high. Accumulated with Information and Complexity did not change the overall high UA and UO evaluation (3.13). Consequently, the context effect on UO and UA is in this project relatively low. 97 As the team was sufficiently skilled (Capability), they were able to work autonomously in phase 1 and remained capable in a small network of actors. Therefore, Social alignment efforts could be reduced by focusing on internal expertise, while including the potential customer for validation. The team established intellectual property protection (1.1.3) to complement lack of 98 development expertise by involving external functional experts. Support from a sponsor close to the team ensured a slightly supportive environment providing the necessary initial funding and freedom to act in phase 1 (task 1). Further, the same sponsor provided the funding needed for upstream phases 2 (task 2.1), 3 and 4 (task 3.1). Thereby, the team had no doubts in task 2.1 about getting necessary funding. The team kept experiments fast and cheap to reduce potential political influence and prevent further dependency of further stakeholders. Fast progress by strict focus and experiments were crucial as the project was under high time constraints caused by seasonality. To encounter disordered/unstable market and business conditions that increase both UO and UA, the team stepwise included UO in order to systematically reduced uncertainty introduced by the context.

In this IP, the integration of context influence only has effect on task 1.1 and tasks 2.1 classification, as shown by Table 14-3. In both tasks the consideration of the context reduces UO values from high to low. In the task 1.1, planningstrategy was recommended instead of experimentation as actually applied. This deviation can have several reasons such as the overestimation of uncertainty with regard to the true needs or wrong assumptions regarding UO. The customer integration is potentially not required and can be neglected, as it may lead to a double-checked validation. In task 2.1, context consideration reduces UO and therefore strives for execution instead of iteration.

Project stakeholder analysis

The naviProM-Net complements the analysis presented in naviProM-Flow and naviProM-Compass based on stakeholder influence and relationships. The latter already uncovered the project's low dependency on stakeholders, which is confirmed by the naviProM-Net analysis presented here. Figure 14-3 visualizes the project's stakeholder network at the end of phase 3, illustrating the continuing strong focus on internal expertisethe core team (T) included eleven experts from IT (initially four), 13 functional experts, and two sponsors. From outside (red-dotted nodes) three external experts were directly linked, two were indirectly linked and 27 early adopters (E) were part of the Smart network. The three external experts provided necessary hardware, software and infrastructure expertise and replaced former internal experts. Like most of the internal functional experts (such as legal experts) they fulfilled their contract showing a neutral (grey node) attitude, with medium bidirectional influence (thin, double-edged arrows). This corresponds to the low political influence (Section 14.4). Business experts provided market expertise and market access. Their neutral to positive attitude and medium influence on the project, combined with the direct relationship between the team and the early adopters further emphasizes the team's social and political independency. The thick, double-sided arrows between sponsors and the team illustrate the high and positive influence of sponsors providing the project's resource stability. In this, naviProM-Net conforms together with the team's view that project responsibility, control and progress strongly depend on the team itself and the support provided by sponsors.

100

The latter are present on a rather temporary basis, safeguarding the next rounds of funding. Of particular interest is the high and positive influence of the early adopters, of which two were involved from the outset and 25 were involved for the future pilot. It emphasizes the close collaboration of the team with future customers, who provide real market validation.

At the time of project documentation, neither the visualized network points with any potential gatekeepers nor the team refers to any. For instance, future funding to realize real market launch cannot be covered by the actual sponsors. It may affect further areas of responsibilities. In this, the team refers to involved business experts, whose support may receive higher relevance, providing potential access to future sponsors and areas of responsibility.

Thus, naviProM-Net supports the team in following their strategy of keeping the stakeholder network as small as possible so as to reduce potential political and social influence. Future customers were involved from the outset and the number increased continuously, while additional functional experts were involved once the scope was clearer. Sponsors were temporarily present. Furthermore, naviProM-Net made it possible to systematically select relevant stakeholders and uncover potentially critical stakeholders as well as relationships that having higher influence on the project with regard to future targets.

Project evaluation and discussion

At the time of documentation, Smart is a project that has been executed successfully based on the project team's intuition, which is why it provided the basis for doing an initial practical validation of naviProM.

The application of naviProM-Flow showed that the actual and recommended task classifications are on the whole in accordance. The existence of different task execution strategies along the project's life cycle is illustrated and enforces the identification of the actual sources of UA and UO. In planning mode, the model shows how tasks are subdivided into smaller tasks decoupling uncertainty. In experimentation mode, it shows that through learning, the team was able to prioritize requirements and schedule related development tasks (e.g., separation of V1 and V2 development tasks). The prioritization generates the basis for properly applying experimentation by focusing the main assumption and passing through the complete experimentation cycle through abstract/concrete and active/reflective mode (see Section 9.2). After each satisfying experiment further uncertainty in UO was stepwise included based on prior prioritization. The team solidified laboratory results with tests under real life conditions. By contrast, the team was able to reduce UA continuously in all tasks related to solution development (in SDW) throughout the project.

Furthermore, experimentation and iteration had a clearly defined scope, all started and terminated by consolidating planning steps. This reflects conscious 101 decision-making based on time-critical deadlines with related scopes rather than on the remaining uncertainty (cf. Section 14.3 and Table 14-1).

Moreover, naviProM recommends plan by subdividing tasks in the case of high UA and low UO, which is what was actually done. Hence, prior tasks are converted in the "planning-task", whereas downstream tasks diverge.

Besides, applying a planning strategy based on the decision to temporarily ignoring uncertainty in UO turned out to be a fruitful decision. Against the background that tasks underlie sequential and reciprocal interdependencies (system approach), a planning-task allows to capture overall progress and structure further tasks from a global perspective.

naviProM-Compass illustrates the low influence of the context in UO and UA. It made it possible to detect e.g. the team's capabilities as well as ensured sponsorship as its sources. Further potential sources of uncertainty such as stakeholder demands, political factors and the team's strategy to systematically keep these factors small are uncovered.

naviProM-Net enriches the analysis by illustrating the team's independence. Not only due to their capabilities, but also due to their independency within the organizational network the team was allowed to work self-sufficiently. Their strong relationships with sponsors provide temporary stability. Thereby, naviProM-Net not only confirms the teams' network perception and strategy, it also makes it possible to detect stakeholders relevant in the future based on midto long-term targets.

Project Analytics -hybrid application 15.1 Project introduction

The Analytics project aims to improve an existing management practice by implementing an analytical method that combines multiple influence factors. The project started with a team of two employees. Both team members could spend 20% of their working time to this project. They did not report to the impacted business function and have no direct access to future customers. One team member has access to the stakeholder network, the other has the required domain knowledge. The latter left the project after the first business pitch (six months). His leaving was compensated in the form of a steering committee comprising two sponsors from strategic business areas, one gatekeeper, as well as three functional experts. After one year, the project was paused due to an unconvincing prototype and a lack of capacity for improving it.

Project management using naviProM

I supported the team Analytics in analyzing the project history retrospectively and prospectively by planning future tasks ("hybrid" application). In order to analyze the project, I joined the team at their project kickoff and in monthly calls in phases 1 and 2. From phase 3 onwards, I pro-actively advised the team using naviProM. As in Smart, I had monthly meetings with the project leader and/or the team members and joined key workshops. During these meetings, I documented actual tasks and stakeholders from the team's perspective, which I subsequently and autonomously classified based on the recommended naviProM task execution strategy. At the end of phase 3, I captured the project context on a macro-level by applying naviProM-Compass.

Project flow analysis

Figure 15-1 shows the naviProM-Flow visualization of the Analytics project. I identified the same three work streams as for Smart, i.e. CDW, SDW, and BDW, 104 which can be divided in five phases. The upstream phase 0 focused on exploring the problem in order to get funding for the initial project idea. Phase 1 focused on understanding and validating the project needs, while phase 2 concentrated on solution exploration. Phase 3 focused on the further solution exploration and validation, which was continued, but then paused in phase 4. At that time, the project was aligned with business sponsors, however there was high uncertainty about the solution's feasibility and viability, while ongoing experiments were stopped (3.1, 3.1.1-3). For the sake of readability, we show the stakeholder dimension only in phases 1, partly 2, and 3.

naviProM confirms task execution strategies

In order to support the project with an entire root-cause analysis, I first focused on phase 1. In this phase, tasks were centered on understanding the problem behind the project's idea (CDW and BDW). Confronted with high UO and UA, the team broke down problem validation (1.1) in three further tasks. According to naviProM they defined the problem (1.1.1) iteratively. The tasks to validate the problem space (1.1.2) and target group needs (1.1.3) were set up as experiments. With the support of an external coach (C), all three tasks had satisfying outcomes and generated the necessary insights for upstream tasks. The integration of the future target group provided early market validation. This is in line with the recommendation based on the naviProM-Grid. From a root-cause analysis we assessed this phase as unobtrusively.

In phase 2, the team satisfyingly designed solution development (2). This was done in three subtasks. They explored potential solutions (2.1) in an experiment (innovation workshop) and iteratively aligned with various numbers of stakeholders (2.2) such as the external innovation coach, internal and external functional experts and business sponsors. Note that the team did no longer include any user or customer at this stage. The impact of these significant changes in the stakeholder network will be discussed in Section 15.5. The outcome of these tasks served as input of the subsequent funding application (2.3). Here the team iteratively developed its pitch. The satisfying outcome of this task (team got the funding to proceed) created freedom to act for the downstream tasks (e.g. task 3).

The task execution strategies chosen by the team were in line with naviProM. Experimentation was chosen when UA and UO were high (high variety of possible solutions, not well-defined requirements, respectively). When UA was low (approach was defined, stakeholder known) and UO high (exact specifications not known or contradicting stakeholder needs), iteration was the execution strategy.

naviProM requires active decision making and prioritization

In phase 3, naviProM was introduced prospectively supporting the project leader to plan and set up necessary tasks. The team (only one person at that time) was no longer supported by an external coach.

105 On a high level, the learnings of phase 2 provided enough input to reduce UO to recommend a planning in task 3 and cope with diversity of solution approaches (UA). After consolidating the learnings and prioritizing the most critical assumptions, we broke the task down into subtasks (explore parameters, apply for funding, and align with stakeholders).

The project leader shared and confirmed this necessity for planning. He did, however, not feel comfortable to deprioritize assumptions brought up by steering committee members. Instead, further tasks were subdivided without prioritization (3.1-3), as depicted by the ongoing planning task. For the subtask 3.1 relevant parameters had to be explored (high UO). Combined with a high diversity of possible solutions (high UA), naviProM proposed to experiment. As prioritization was not done appropriately, this experiment led to unsatisfying outcomes.

Satisfying results require proper task execution strategy of the naviProM

Other important assumptions concerning data availability, data collection and measurement technologies were addressed in parallel (3.1, 3.1.1-3). Even when the task execution strategies for these activities were derived in line with naviProM, they did not yield the necessary insights fast enough. Experiments were executed as iterations so that experimentation cycles were not sufficiently completed. Assumptions were set up and ideas derived in collaboration with functional experts, however never made concrete and tangible. Thus, experiments got stuck somewhat as abstract iterations. The outcome was a list of additional assumptions and ideas instead of the needed insights. Limits in available resources lead to another effect: Due to mutual dependencies, task 3.1.3 also had to be stopped ("!") caused by lacking input. By contrast, time-intensive stakeholder alignment resulted in a satisfying outcome (3.2), though lacking a clear strategical mandate.

From this, we can derive that the main sources of problems created in phase 3 are the following: (1) Decisions and prioritizations to appropriately mitigate uncertainty in UO have not been made in time. (2) The task execution strategy was not appropriate. It caused lasting complexity (UA) manifested in the breadth and variety of experiments and a lack of insights and validation (UO).

In phase 4, experiments were resumed, but quickly stopped because of the same reasons as in e.g. 3.1.

Although we cannot prove whether the project would have been a success if the respective tasks had been executed according to naviProM, the project leader clearly confirmed the relevance of naviProM recommendations, as well as their significant contribution to raising his awareness of the significance of different task execution modes. There are also aspects not covered by naviProM-Grid, which will be elaborated on in Section 15.4. For instance, the lack of team resources for properly executing time-intensive experiments.

At that time, the project was aligned with business sponsors, however there was high uncertainty about the solution's feasibility and viability, while ongoing experiments were stopped (3.1, 3.1.1-3).

107

Project context analysis

In order to include context uncertainty in the hybrid naviProM application, we applied naviProM-Compass, though at a project-(macro-)level only. The result is shown in Table 15-1 and visualized in the naviProM-Compass (see Figure 15-2). Together with the team, I determined the weighting of each context factor as follows: 0 for speed, 3 for capability, social, and dynamics and 1 for all other context parameters. The calculated context value for UO and UA is 3.00 and therefore high. Combined with the values for Information (3) and Complexity (4) there is a high UO (3.00) and high UA (3.50).

Table 15-1: naviProM Compass evaluation -Project Analytics

As described in Section 15.3, the project was confronted with high complexity in particular due to a high diverse range of actors, and a very high number of approaches influencing UA. Furthermore, Ambiguity was high as the problem was not specified and requirements could not be translated into specifications. These was combined with new needs (Novelty).

With respect to the context, the team leader indicated the following factors mainly affecting UA and UO: Capabilities, including a lack of capacity and expertise that were only partially covered. This social environment was judged as intractable based on conflicting stakeholder needs as well as unclear responsibilities. Dynamics was evaluated as chaotic or very unstable due to organizational restructuring, fluctuations and dynamic market conditions.

Due to the project's novelty, expertise was either scattered, difficult to access or partly non-existent. This hampered specification of targeted outcome and the derivation of necessary actions. Not only this explains why a variety of additional internal and external experts (e.g. task 1.1.2, 1.1.3) were involved, but also points

109

to the demand for a variety of experiments. This influence was further intensified by one team member leaving the team (reduced capacity).

Figure 15-2: naviProM-Compassproject Analytics Second, the team evaluated Social as intractable, since diverse stakeholder interests had to be unified before the project could actually start. Further, the project was not included in any business strategy (criticality: low) and lost competition against other strategic targets. Nevertheless, the IP got increasing awareness and interest depicted by the satisfying stakeholder alignment (e.g. task 3.2, 4.3). The number and diversity of stakeholders, however, increased complexity, consumed scarce capacities, hampered decision-making ability, and therefore inhibited project progress which also could have been better prioritized or decoupled. The project leader, for instance, felt not comfortable enough to prioritize in task 3.

Third, chaotic and very unstable business (e.g. restructuring and team fluctuation) as well as market conditions (e.g. diverse, scattered research units) increased UO and UA. The highly uncertain, scattered research field, paired with a lack of stability and capability, illustrates why the team leader was not able to execute required but time-intensive experiments. He instead concentrated on linking with the experts needed (see Section 15.5).

Project stakeholder analysis

The application of the naviProM-Net complements the hybrid application of naviProM. Figure 15-3 shows the network at the end of phase 1. The network on the bottom left constitutes the actual business area of the team members. Here, the sponsorsin consultation with the gatekeeperprovided sponsorship for the first rounds of funding (phase 0). The external coach represents the internal entrepreneurship program providing resources for phases 1 and 2. The network in the lower right includes potential customers and two early adopters having a positive, high influence on the project. Those and other functional experts were involved in first validating the problem in phase 1. At that time, a large variety of functional experts were involved. These were mostly not interlinked and showed a medium to high influence towards the project. Figure 15-4 shows the stakeholder landscape at the end of phase 3. At the end of phase 2, the project had gotten strategic relevance leading to an extended, cross-functional steering committee, whereas one of the two operational team members left the team. Hence, the red boxes illustrate the eight clusters (A-H) of stakeholder groups that were involved at that project stage.

Whereas the top networks (A, B, C) represent the networks of project sponsorship, constituting the potential area of project implementation, the lower network H represents the actual business area of the team members. Stakeholders in networks D, E, and F provide access to the required functional expertise that make it possible to explore fundamental uncertainties within the project (see tasks 3.1, 3.1.3 in Figure 15-1). Internal experts in D provided domain knowledge (e.g. task 3.1.1), while internal and external experts in E contributed IT knowledge (e.g. task 3.1.2). The external experts in F provided the access to missing technical knowledge, however they some showed a negative attitude and/or resistance to the project (white nodes). The network in G shows the high influence of favorable early adopters as well as six neutral customers who have a strong relationship (thick arrow) to one internal functional expert (F). The size and diversity of the project's network indicate the level of its complexity and point to the effort involved in stakeholder management. The light blue nodes indicate the extended steering committee members depicted as sponsors, functional experts, and gatekeepers, which had been established by the team. They successfully created the strategic link between essential parties (A, B, 112 C, D, H), while the team failed to include parties E, F, and G in providing potential access to the most critical knowledge (see task 3.1, 3.1.1-3 in Figure 15-1). Their membership of different clusters points to the diversity, conflicting demands and the lack of collective decision-making. At the same time, it indicates the wide project awareness that has been achieved. Alongside these representatives was a steering committee rather than an operative group of experts being temporarily present at decision points.

Project evaluation and discussion

First, naviProM-Flow gave a significant contribution to systematically analyzing the project. From the naviProM perspective, phase 1 does not merit special attention. In phase 2, results were also satisfying, while the involvement of a large and diverse number of stakeholders as well as lack of prioritization of various (partly contradictory) requirements indicate potential sources of lasting uncertainty. Phase 3 was identified as the key source of lasting uncertainty, in which the external methodical coach was not available anymore, either. Based on the naviProM recommendation to apply planning in order to consolidate the learning generated in phase 2, and the team followed the naviProM recommendation, they subdivided further tasks without upfront prioritization. Thereby, the selection of each task execution strategy was in line with the naviProM-Grid recommendation. However, the actual task execution was not done properly (lack of prioritization, incomplete experimentation design). Lack of capacity and a lack of progress based on unsatisfying results (lack of validation and learning) caused lasting uncertainty and ultimately resulted in a project pause.

Second, naviProM-Compass made it possible to detect the three main sources of uncertainty, identifying Social as high due to the integration of a highly diverse stakeholders not providing direction and guidance. Furthermore, Dynamics was evaluated as high due to continuously changing conditions, as was Capabilities, since the team was partly skilled, although crucial operative skills were missing.

Finally, the naviProM-Net complemented the analysis, illustrating the successfully established and extended project team including representatives of essential departments. These representatives but had the role of a steering committee rather than an operative one (which was actually needed). Moreover, the visualization uncovered critical network gaps, as the team failed to create sustainable relationships with three key parties.

In summary, the three tools helped to detect key progress within the project as well as the main sources of the project's problems based on task level. Although the lack of capacity or team fluctuation could not have been prevented by applying naviProM, I assume that a naviProM-compliant execution would have helped to systematically mitigate uncertainty.

16 Project App -hybrid application

Project introduction

The third, still ongoing project App is of the type product-service-system [START_REF] Meier | Industrial Product-Service systems-IPS2[END_REF], where a service is to be designed that changes the behavior of several end-user groups. Therefore, the actual end-user expectations and requirements still needed to be co-developed with the actual potential design solutions. One would consequently expect a close interrelationship between CDW and SDW.

Project App belongs to a business area that has direct access to external customers. The IPs team consists of five internal employees working ca. 10-20% of their time on the project. One of them has the required knowledge about the market and the end customer, two have the necessary domain knowledge, and the remaining are part of company IT. Supported with an internal entrepreneurship program, the prototype reached TRL 8 after a project duration of two years and is about to be available to consumers (TRL 9).

Project management using naviProM

I accompanied the project App from the beginning, while we applied naviProM together in planning mode from the end of phase 2. Before that, I analyzed project progress in phase 1 and 2 together with the project leader and the project team using naviProM-Flow. We also did a naviProM-Compass analysis at project level at the end of phase 3, as well as a naviProM-Net analysis of the project team after phase 2. Based on bi-weekly meetings and quarterly workshops, naviProM-Flow and naviProM-Compass were used without explicitly including context parameters. I applied the naviProM-Net in each phase, while the most relevant networks in phases 1 and 3 will be in focus within this thesis.

Project flow analysis

The hybrid application of naviProM finished at the end of phase 4 (see Figure 16-1). The differentiation between CDW, SDW, and BDW also fits with this IP. 114 Phase 0 focused on structuring funding and elaboration of a general idea approach, phase 1 on understanding customer needs and business alignment, and phase 2 on solution development and funding. Phase 3 concentrated on solution validation and development, while phase 4 focused on preparing implementation and integration of the solution in the established organization. The future phase 5 will focus on market launch and post launch care. Given the special characteristic of this project highlighted in Section 16.1, phase 3 and 4 in CDW and SDW were of special interest and are therefore investigated in detail.

In phase 1, the priority was on the CDW so as to better understand the future target group. Supported by an external coach (entrepreneurship program) and applying experimentation, the team observed the current behavior of the target group. The insights generated made it possible to divide the target group into buying customers, early adopting customers, and users.

Based on this, the team developed an initial draft concept in phase 2 in order to get internal funding and continue. Both phases were executed according to what naviProM would have recommended. The team gathered valuable insights which served as a basis for future tasks.

Phase 3 aimed to validate and develop the solution and concentrated on both SDW and BDW. Therefore, the team divided the task into three sub-tasks. First, the team followed the recommendation of validating the service solution (3a.1) under real market conditions based on experimentation (as assumed in Section 16.1). Since the application of the service requires an interaction and behavioral change in both, the future customer (positive attitude towards the project) and users (showing a negative attitude toward the project in task 1.2), both parties were integrated to generate further insights. Second, two parallel tasks were set up to develop the solution, the technical app and its content. Following naviProM, the team made use of iteration, as the action was clear, whereas its technical and content specifications were uncertain and had to be validated based on customer feedback. Due to unsatisfying outcomes in 3a.1 and 3a.2.1, which served as an input for 3a.2, technical development had to be paused temporarily. Further tasks, 3a.3 and 3a.3.1, resulted in satisfying outcomes.

A product-service-system project requires close interrelationship between CDW and SDW

Real-life validation ensuring the service's usability in the market was not integrated. Both experiments failed. While hypotheses had been isolated, a prototype and test case had been set up, but the team did not execute the test in real life conditions and complete the experimentation cycle. They were convinced that they had captured the right solution needs but lacked the courage to test this with a prototype with future users (improper experiment design). Combined with team fluctuation, 3b.2 led to an unsatisfying outcome. The subsequent experiment 3b.2.1 had to be stopped due to technical problems and limited customer access causing an insufficiently large sample. This is why I recommended setting up two further experiments in a second trial.

The unified solution development task (3b.1), in contrast, resulted in a satisfying outcome. They tested the application in a laboratory set up. However, users were not involved, and the experiment was not synchronized and consolidated with parallel CDW experiments.

Decoupling CDW tasks could have reduced effort and may have allowed easier and faster progress in SDW tasks. For this product-service-system project (see in Section 16.1), this is however not valid. The expert advising service is in the center of the project App requiring behavioral change from its users and customers. The application itself is only the platform for providing the service.

In the subsequent phase 4, there was lasting uncertainty about product-service usability and acceptance (based on the inverted outcome of phase 3). Nevertheless, the team focused tasks on implementation (4.1-3) and launched the solution (5.1), although they have not learned from their solution's application in practice yet. Hence, I claim that (1) lack of solution validation by customers in practice due to (1a) improper experiment design, (1b) limited or difficult customer access, (1c) reluctance of receiving negative feedback, and (1d) the team´s conviction of the solution's value caused continuing risk of launching an application that may not be accepted.

Project context analysis

At the end of phase 3, the decision was made not apply the naviProM-Compass on a project (macro-) level (see Table 16-1) because of the low influence of the project context. Based on the set weighting of 1 for all context parameters, the context values of 1.75 (low) in UO and with 2.13 (low) in UA made it possible to quickly confirm the low context influence in project App.

As mentioned in Section 16.3, Ambiguity (Information) was caused by the fact that the customer could not be specified (in phase 1) and requirements could not be translated into specifications. Further, the new need and context (Novelty) caused high UO. This market uncertainty dominated throughout the project life cycle. With respect to UA, the team referred to high complexity caused by a high number of potential approaches and a high level of interdependency.

Of interest regarding the context are Capabilities. The team felt mostly skilled (2) to understand the fundamental problem behind the idea due to prior experience and business knowledge. This scientific-based knowledge may explain the high level of self-confidence in the team, and reluctance to apply experiments in order to validate the solution's usability under real life conditions. By contrast, they felt only partly skilled (3) for the particular tasks they decided to hand over to external experts.

1 3 + 3 -Partly skilled Institutional 1 2 -2 -Few constraints Institutional 1 2 -2 -Few constraints Political 1 1 -1 -Supportive Political 1 1 -1 -Supportive Social 1 1 -1 -Collaborative Social 1 1 -1 -Collaborative Criticality 1 2 -2 -Moderate Criticality 1 3 + 3 -High Speed 1 2 -2 -Regular Speed 1 3 + 3 -Fast Dynamics 1 2 -2 -Ordered/few instabilities Dynamics 1 2 -2 -Ordered/few instabilities Individual 1 2 -2 -Neutral Individual 1 2 -2 -Neutral Context 1 1.75 - Context 1 2.

Project stakeholder analysis

The application of naviProM-Net shows the strong market focus in phase 1 (Figure 16-3). Hence, the involvement of users, two early adopters and two customers provided the necessary market insights for differentiating and specifying the target groups (task 1.2, 1.3). For instance, the neutral to negative attitude of one of the target groups made it possible specifying them as indirect users. The strong initial relationships between the core team, sponsors and gatekeepers, all showing a neutral to positive attitude towards the project, underline the strategical commitment and relevance of the project. This support 119 provided in the background relates to the perceived stability, as well as the political and social support mentioned in Section 16.3. In phase 3 (see Figure 16-4), the team has extended the network to consist of four internal networks, including (1) technical app development, (2) content development (3) market access, and (4) marketing strategy and business alignment along with one external network including an extended number of early adopters and users. As each team member had a strictly separated area of responsibility, I decided together with the team to present each team member with an individual "T"-node.

Thanks to individual background, each of these network clusters is covered at least by one team member. This broad network coverage enabled the team to work in parallel work streams and tasks. The lack of links between these five networks illustrates the crucial interface role of the core team. It demands close interaction between all team members to ensure knowledge diffusion.

Against this context, there was only one core team member and a further functional expert who had direct access to the external market in order to carry out experiments. Time-intensive experiments combined with team fluctuation 120 caused limited capacity for conducting experiments (stopped tasks or unsatisfying outcomes).

The development of marketing material or the development of the solution could be completely delegated to external functional experts (e.g. content solution development, technical solution development network). Thereby, the core team members coordinated tasks and validated the progress by giving feedback. To conclude, the network visualizations underline the need for close team interaction in order to consolidate information about parallel tasks and uncover further reasons for unsatisfying experiment results. As already stressed in project Smart and partly in App, customers and/or users were involved from the outset in continuously increasing numbers, while functional experts were involved later, and sponsors were present only temporarily. Thus, progress was still in the responsibility of the core team.

Project evaluation and discussion

The hybrid application of naviProM made it possible to quickly capture a satisfying project history in phases 1 and 2. Furthermore, it supported the project leader in setting up tasks according to the specific requirements of a productservice-system of uncertainty in phases 3 and 4. Tasks in phase 3 were, however, not executed as recommended by naviProM. This turned out to be the source of problems that appeared later on. The required solution validation under real life conditions failed due to several reasons, such as improper experiment design, lack of capacity, limited customer access, as well as the team's belief in the solution's added value. By contrast, the progress in SDW was fast and easier, though not valid for this project type as it was carried out without synchronizing with CDW insights.

Nevertheless, the team experienced the value of continuously re-assessing tasks in order to react appropriately to changes in uncertainty levels. They confirmed that different execution strategies are necessary, whereas the wrong assessment of uncertainty could have a negative effect on project progress. While experiments were prospectively seen as unnecessary and wasted time, the subsequent visualization of historical data in the naviProM-Flow plan transparently showed the lack of data. In particular, they confirmed that experiments would have been necessary.

As already illustrated in the previous use cases, the team consciously defined decision points by setting up planning tasks. Serving to consolidate prior learning and to derive next steps, these tasks were executed by the whole team, whereas all other tasks were executed by individual team members only. Further, the separation of the project in four phases greatly facilitated the application of naviProM. The team, however, became aware of timeliness of task execution only retrospectively.

The application of naviProM-Compass provided further background information for better understanding the main drivers of uncertainty. Ambiguous information and the novelty to the market created high UO, whereas the high complexity mainly affected UA. The context was of low influence. The team's heterogeneity provided the basis for specifying underlying requirements. Their acknowledged and proven expertise may have hampered the team's willingness to apply experiments and strengthen their belief in the actual usability of their solution.

Finally, the naviProM-Net helped the team to detect and analyze decisive stakeholder networks and gaps. The visualization e.g. uncovered the missing links between individual, relevant networks, and therefore pointed at the important role of the team, ensuring enough knowledge diffusion. Further, it showed that time-intensive experimentation was challenged by limited capacities, while all other tasks could be delegate to external functional experts.

Project Training -prospective planning 17.1 Project introduction

The key characteristic of the fourth case study project Training was that it aimed to qualify users in correctly using products. This training included practical experiments depending on seasonal conditions.

The project team consisted of three internal employees working in different departments in the same business area. One of them had the required domain knowledge on the local, operational level and access to the market. The two others had the knowledge on the global, strategical level. They spent about 20% of their working time on this project. Supported by a corporate internal entrepreneurship program, the prototype reached TRL 7 after 1,5 years.

Project management using naviProM

Unlike the three previous projects, I had the opportunity to accompany this project throughout its entire duration. I was therefore able to apply naviProM in prospective planning mode based on monthly face-to-face meetings with the team. In order to define a starting point, we established the initial WBS as depicted in Figure 17-1. We decided to distinguish three primary work streams as core structure: First, CDW as we found that the knowledge about the target group and market needed still to be elaborated. Second, SDW in order to derive tasks to develop the solution. Third, BDW since a complex affected stakeholder network that might be affected on the global level.

Guided by the entrepreneurship program, in terms of timing we envisaged four essential phases (red dotted lines): Passed phase 0 served to apply for funding. Phase 1 was to concentrate on understanding the customer needs and business alignment. Phase 2 should focus on training development and business alignment. Phase 3's purpose was to validate the training and customer acceptance. Finally, phase 4's mission was to implement the training and integrate it into the established organization.

As illustrated by the light grey boxes, the team first defined the major work packages (i.e. get funding). Thereby, major objectives of phase 1 could already be precisely scheduled (black headlines) based on historical data, whereas work packages in later phases were only roughly scheduled (grey headlines). These were iteratively refined over the course of the project. Moreover, predetermined organizational events (kick-off meeting, pitch event) and team availability, team meetings, workshops, were roughly scheduled. Based on the WBS, we used naviProM to break each work package down into tasks throughout the entire project duration so as to actively accompany the project team and especially the project leader. In order to systematically capture and assess each task, we put the task planning for each phase in a table by following the tool (Section 9.2) without including Compass metrics. Each task is visualized in the naviProM-Flow including its Grid classification and outcome evaluation (OE) (see Figure 17-2). In doing so, we focused stepwise only on the next phase. We added OE to the table and the naviProM-Flow once the task was performed, while at the end of each phase we broke down tasks for the next phase.

Furthermore, stakeholders for each task were captured and within the naviProM-Net in each interview. naviProM-Compass was only applied retrospectively at the end of phase 3 in order to assess whether the compass would have had a particular influence.

Project flow analysis

In phase 0, the team started with a clear idea, which specified the overarching targeted outcome of phase 1. Based on the assured support of the entrepreneurship program, phase 1 was started by breaking down principal work packages of WBS (e.g. define problem, understanding, set up network) into concrete tasks as illustrated in Table 17-1. These tasks as well as their relationships were visualized in the naviProM-Flow (see Figure 17-2).

In phase 1, tasks were concentrated on desirability and were spread over CDW, SDW, and BDW. Following the naviProM-Grid recommendation, the team planned their approach (1) and broke down their idea into three exploratory and diverging tasks (1.1-3). The team further divided the overarching "validate the problem" (1.1) into three tasks. The onerefining the problemwas approached by iteration (1.1.1). The two other tasksvalidating and specifying the target group (1.1.2) and their needs (1.1.3)were planned as experiments. The retrospective analysis, however, suggests that these experiments were in fact iterations (1.1.2-3) where feedback was collected through questionnaires. A real experiment may have prevented the need for experiments in phase 3 to specify the real customer (3.1.4). Nevertheless, gathering customer feedback provided decisive insights to validate and adjust the problem behind their idea. The experiment used in order to invent solutions (1.2.2) confirmed the idea of the team and failed, as it did not provide new insights. This points at an overestimation of UA by the team or their strong influence on the experiment. Based on naviProM iteration would have allowed the team to start developing the solution instead of investing time in an experiment.

In the third task 1.3 within BDW the team started from early on to align with global stakeholders. Its satisfying outcome complements the outcome of 1.1 and 1.2 serving as input of the pitch development (1.4). Depicted by satisfying outcomes and the high interaction of individual tasks within the CDW, point at a steep learning curve. Although the pitch presentation formalized stakeholder alignment (1.4), it did not provide sufficient funding to develop a solution in subsequent step. Given the results of phase 1, the team modified the WBS of phase 2. A further funding application was necessary to secure funding (see Table 17-1). Figure 17-3 shows the tasks' focus on SDW and BDW to determine the economic viability and adjusting the deliverables to future sponsors need. Anticipated seasonal conditions forced the team to postpone CDW-tasks into phase 3. At the end of Phase 2 the team received the necessary funding for the downstream tasks. With phase 2 the support by the entrepreneurship program represented by the external coachended at the close of phase 1. This also meant that the project team had to find a new sponsor for future activities. A process that required time and determined the duration of phase 2. At the beginning of phase 3 the WBS was reviewed based on the results of the previous phases. The objective of phase 3 was to evaluate the technical feasibility of the solution. To validate the service solution in a first local use case, the team decided on experimentation (3.1.6.) rather than iteration. Thus, both UO and UA were considered as uncertain. Part of the explanation is that the tasks (1.1.2-3) were executed as iterations instead as the intended experiments. A positive outcome should have eliminated the UO uncertainty. It also confirms the unsatisfying outcome of experiment 1.2.2, which aimed to reduce UA but did not.

Validate idea & understanding

For reasons of unexpected weather conditions, the experiment in the context of the use case (I) lasted four months. During that time the target group was trained. However, the solution could not be validated, since weather conditions prevented the target group from applying the training content and thereby evaluate the training's actual value. Due to the lasting uncertainty, the team had to repeat the experiment in the setup of a weather independent use case (II) (3.2.4), which led to satisfying insights and the validation of the 129 solution. The outcomes of case (I) tasks flow as input of case II tasks serving the same targeted outcome of validating the service solution. Their relationship is depicted by the connecting arrows between e.g. 3.1.6 and 3.2.4.

In the still ongoing phase 4 (grey colored tasks: 4.1-2) there is still uncertainty about the future business sponsorship needed for scaling the solution and its integration in the established project portfolio.

Based on this analysis driven by naviProM, we can conclude that first unclear and changing organizational responsibilities and second unexpected weather conditions have been the primary drivers for the lasting uncertainties in Training.

naviProM provides an overarching project overview

The initial WBS divided the project in its main phases, workstreams and addressed objectives. Although the WBS were adjusted along the project life cycle and provided sufficient orientation. It helps to keep an overview of the project while detailing work packages when necessary. For instance, the team foresaw that seasonal conditions would prevent tasks in CDW during phase 2 and decided for fast experiments in phase 1.

naviProM supported the project manager in identifying the appropriate task execution mode as well as the right moment to switch between them. This supported a targeted uncertainty reduction throughout the project (e.g. validated desirability). This can be seen as with increasing progress, the execution modes that reduce outcome uncertainty (iterate and experiment) have become less frequent.

As mentioned in Smart, overarching tasks (e.g. 1, 2) start with a planning step to structure and break down subtasks. Thus, naviProM allowed the team to hide uncertainty on one level (e.g. 1, 1.3) and deal with it in the subtasks. Thus, it prevented the team from being overstrained (or paralyzed) by uncertainty. naviProM supported the team in systematically detecting uncertainty and applying the best approach in every situation.

Teams can over-and underestimate uncertainty when applying naviProM

Comparing the columns R and A in Table 17-1 and Table 17-2 reveal that the team mostly followed the task execution mode recommended by naviProM. However, in phase 1, the team underestimated uncertainty with regard to the action (1.1.2-3). These experiments were applied as iterations. Thus, critical project uncertainties were dragged along and caused timeintensive experiments in phase 3.

In phase 3, by contrast, the team overestimated uncertainty with regard to the action by making use of experiments instead of the recommended iterations (3.1.6, 3.2.4). Recommended iteration in SDW would have generated the necessary user feedback in order to validate and continuously develop the final solution. Strictly applied experimentation considers the solution as a hypothesis to be tested and requires rejecting the solution where there is a rejected hypothesis. Lessons previously learned, such as validated early adopter needs (1.1.2) did need to be questioned. Same as in 1.2.2 also in tasks 3.1.6 and 3.2.4 uncertainty was overestimated. The used experiment did not generate additional insights and was more time intensive than an iteration, would have been. Furthermore, an iteration is designed to generate a tangible outcome whereas experiments focus on learnings.

The differences in classification show that overestimated uncertainty regarding the actions may slow down project progress, though not necessarily stop it. The fact that the team set up a second experiment after an unsatisfying first trial proves the team's awareness of the remaining uncertainty (3.2.4).

Table 17-2

Project context analysis

The naviProM-Compass was applied retrospectively to Training to investigate whether the context had a significant influence on the project. Together with the project leader, we chose the following weighting (see Table 17-3): 2 for the overall UA and UO context versus 1 for Complexity and Information. 5 for Social and Dynamics, 1 for Ambiguity, Novelty, Political, Criticality, Speed, and Individual, and 0 for Capabilities. With regard to the context related to UO Institutional is weighted with 0, while it is weighted with 1 related to UA.

The calculated context value for UO is 2.79 and for UA is 2.73 and both are therefore high. In combination with low overall value in Information (2) the overall UO value changes from low to high (2.52). UA remains high when considering the context as the value Complexity is high. Figure 17-5 visualizes the results in the naviProM-Compass. Especially at the beginning of project Training, customer needs were not completely specified (Ambiguity). Its combinations with new IP needs (Novelty) temporary led to high UO (Section 17.3, tasks 1.1.2-3). Complexity was high and by consequence UA due to many and diverse actors (see also Section 17.5) and approaches as well as the high degree of interdependency.

Context related parameters mainly influencing UO and UA were the following: Political as the future sponsorship of Training was not specified. Social was evaluated as conflicted, since many internal and external stakeholder groups (partly contradictory) were affected. Dynamics was evaluated as disordered and unstable due to unclear responsibilities and seasonal conditions (external market conditions). Individual was evaluated as Based on prior experience, the team had the required capabilities in order to understand the IP's specifications and to determine and execute the necessary actions. From the outset, the team expected a collaborative teamwork, but was aware of a potentially conflicted social environment. Its combination with low Criticality due to lack of formal legitimation made the team set up business alignment tasks from the beginning.

With regard to Political, a predicted restructuring of the organization caused fluctuation, unclear responsibilities, and an unsecured budget, which led to high UO. For instance, funding negotiations to ensure future sponsorship took long time (see Section 17.3, task 2.2). Nevertheless, political 135 influence could be reduced along the project life cycle as generated data and facts (Section 17.3, task 3.2.4) led the necessary political commitment (Section 17.3, task 3.3).

Further, the team evaluated Dynamics as unstable and disordered (3). This however included expected internal conditions, but also underestimated or unpredicted external market conditions. Seasonal conditions prevented e.g. the validation of the training-solution (task 3.1.6) and caused a lack of stability reinforcing UO and UA. Hence, the team lost much time for validation. The repetition of the experiment with a new setup made it possible to successfully validate the solution independently from seasonal variations (decouple uncertainty). At the end of phase 3 the business knowledge gained and assured sponsorship (see SDW, BDW) made the team downgrade the influence of (internal) dynamics enabling better predicting of changing conditions.

The retrospective application of naviProM-Compass made it possible capturing influencing context parameters in a structured way. By contrast to the team's intuition, the Compass metrics could have helped the team to also detect the influence of the Dynamics of the external market conditions as well as the degree of influence of Political beforehand. Both had been underestimated by the team and caused time to be lost.

Project stakeholder analysis

Applying of naviProM-Net underlined the high stakeholder involvement in the IP. The team had built two main networks at the end of phase 1 (Figure 17-6): First, the global network that links the internal stakeholders involved at a global level (left). Second, a local network that links all internal and external stakeholders at a local level in terms of the first use case (top right).

Based on experience, the core team had a broad network coverage, enabling them to foresee social challenges and identifying relevant stakeholders in terms of potential project resistance or support. Therefore, the team was able to systematically identify, understand, and activate key stakeholder groups of low, medium, and high influence. Long-term ownership, for instance, was not specified at the time when the team focused stakeholder alignment tasks on gatekeepers and potential sponsors. Most of the directly linked stakeholders have a positive or neutral attitude toward the project and are involved in the SDW and BDW. The extended team member "T'" is of particular interest (actually a functional expert), as he manifests the only link between the global and the local network, though this is very strong. This strength is based on a trust-based relationship between T and T'. Both networks are egocentric as almost all stakeholders are only linked through the core team members. The local network forms the access to the market represented by the potential customers and early adopting users, who are 136 exclusively involved in the CDW in phase 1. Thus, the experiment tasks (e.g. Figure 17-2, tasks 1.1.2-3) are rather concentrated in the local network. In phase 3, the team extended the network. While the global network was reduced to the relevant stakeholders, the local network for the first use case (top right) was extended as well as, a further local network for a second use case and a business network were set up (Figure 17-7).

According to the SNA, the team concentrated stakeholder involvement on stakeholders with medium and high influence, whose attitude with respect to the IP has, in part, become more positive (grey to black colored node). This attitude shift illustrates the required agreement of the next funding round at the end of phase 2 as well as specified responsibilities after lengthy negotiations (task 2.2). The light blue colored nodes show the main actors driving the project progress and integration on an operational level. They all belong to the global network. In this context, the project team emphasized that informal supporters shaped the project idea through new ideas, contacts, complementary initiatives, etc.

The main link between the global and the two local networks through the core team members ensured the flow of resources. It further provided financial and political support from the global to the local networks along with the flow of market knowledge from the local to the global network. However, it shows the high dependency of the project success on the core team, which links and maintains these networks. Red colored arrows illustrate the team's initial attempts to establish a stable network relying on further links between the local networks and the global network. The team stressed that the customization of dialogues to highlight individual project benefits (e.g. savings, sustainability, increased effectivity or efficiency of established 137 processes) was crucial. It allowed to individually respond to the differing interests of the stakeholders involved. Despite the positive attitude and highly influential relationships of local stakeholders, we can assume that sustainable IP success still largely depends on the team. Their commitment is decisive to establishing a stable infrastructure with clear global and local network responsibilities and strong relations. The team started initial approaches (for instance Figure 17-2, tasks 3.3-4) to link and integrate the service solution in complementary, though established organizational networks (grey box). This is depicted by the individual links to the business networks ("O"-typed triangles). In the long term, these links provide the basis for others to take over responsibility, allowing the team to withdraw from the IP.

Thus, naviProM-Net provided a structured overview of the large and diverse stakeholder network of project Training. It uncovered strategical network roles and links, as well as missing links, e.g. between the local and the global network. The visualizations created both awareness and the relevant data basis to derive network strategies.

Project evaluation and discussion

The project Training is the only IP which I was able to apply naviProM to in a prospective way from the outset. Its application helped the project 138 manager to systematically break down WBS tasks at the beginning of each phase and to further structure, analyze, and classify tasks. The structured data created a basis for not only boosting the awareness within the team, but also making it possible to actively change modes within the ongoing project. It further enabled the team to quickly review deviations between recommended and actual classifications (3.1.6) and provided an overview of satisfying and unsatisfying outcomes (e.g. 3.1.5) requiring for e.g. further experimentation (3.2.4). Given the data collected in tabular form, the naviProM-Flow helped the specification and analysis of critical task relationships such as 2.1 and 2.2 as well as key stakeholders, making it possible to then reduce uncertainty throughout the project life cycle (e.g. validated desirability and usability).

The naviProM-Compass complemented the team's gut feeling with metrics. Its retrospective application confirmed the already expected parameters Social and (internal) Dynamics influencing UO and UA. External market dynamics due to seasonal variations as well as Political were however underestimated. Thus, the prospective application of the metrics might have created the necessary awareness to better deal with those and thus prevent time being lost.

Finally, the naviProM-Net supported the project manager in detecting critical, though thin, network links between the local and the global market. It further helped the team to systematically detect crucial network roles as well as their long-term position within the IP network.

Discussion

This grounded field study shows that uncertainty constitutes an integral part of IPs, highlighting the need for a decision aid for project managers that will consider individual IP conditions. The application of naviProM provided valuable insights that the project managers and team members of the four investigated IPs had not been aware of before. Major findings are summarized in the following (see also Table 18-1).

The retrospective analysis in the project Smart made it possible to identify success patterns in terms of tasks and task flows and associated stakeholder networks, as well as the context which the IP is embedded in. The Smart project's success was based on task execution modes which naviProM would also have recommended, and therefore validated naviProM. Its hybrid application allowed the teams Analytics and App to detect root causes in areas that had not been taken into account by them before the application of naviProM in planning mode. The prospective application in team Training helped the team to plan the project tasks by systematically considering data, the given sources and the degree of uncertainty.

Applying and validating naviProM in the three modes (analysis/retrospective, hybrid, planning/prospective) in practice allowed to answer Q2. The definition of individual project types and the derivation of necessary tasks on a global level (e.g. high user involvement in a service development project) provided guidance for advising the teams. naviProM-Flow (structure-based) and naviProM-Task (content-based thanks to the tabular content representation) provided the necessary visual overview to capture patterns, progress and discrepancies.

The continuous classification of tasks into individual execution strategies is of high relevance as demonstrated by the fact that teams who have been executing tasks according to naviProM have been successful so far. By contrast, those who did not were rather unsuccessful with regard to mitigating uncertainty and risks (Analytics and partly App). This highlights the importance of the proper application of each approach. In particular, the teams found it challenging to pass through a complete experimentation cycle and generate as much insights as possible from it. Staying in the abstract mode by defining hypotheses and developing ideas or building prototypes without testing with the customer is time-consuming and does not generate valuable insights. Even more important is the systematic breaking down and prioritization of tasks, as confirmed by Training, App, and Smart. This provides the necessary focus ensuring fast progress (e.g. steep learning curves). In this context, planning has a special role. In planning tasks, prior tasks were converted at the beginning of each phase, whereas downstream tasks diverge. Thereby, they serve as consciously set decision points, in which existing uncertainty in UO is temporarily excluded or accepted. All teams confirmed that naviProM created awareness of changing levels of uncertainty per task. naviProM significantly incited teams to systematically switch between the four task execution strategies and change behavior appropriately. All project leaders experienced the value of frequently reassessing tasks in order to react to changes in uncertainty levels appropriately. Furthermore, teams were guided in making decisions under conditions of uncertainty. The method and related tool set helped them to decouple uncertainty by breaking down tasks and prioritizing the most critical objectives. In this respect, they all emphasized the value of enriching the qualitative evaluation based on intuition with the metric-based quantitative evaluation. All of them confirmed that a wrong assessment of uncertainty could have hador actually did havea negative effect on project progress. Whereas overestimation could lead to increased effort without creating value, underestimated uncertainty may lead to protracting uncertainty, wrong decisions and project failure (in particular project Analytics). Based on this validation in practice of naviProM, Q3 can be considered as answered.

In terms of context, naviProM-Compass supported project managers by enriching their intuition with a metric-based uncertainty evaluation. Visualizing the project's uncertainty landscape made it possible to capture the areas in which uncertainty may arise systematically and in good time, and also to derive strategies on how to consider, reduce or isolate influencing parameters.

Thanks to its a detailed context analysis of the stakeholder dimension, naviProM-Net supported project managers in regularly analyzing decisive stakeholder networks, as well as deriving strategies to address e.g. network gaps with respect to missing or weak links to relevant stakeholders, successcritical stakeholder or network dependencies, negative attitudes of highinfluence stakeholders, etc. In all four IPs, users and customers were involved at the beginning to better understand the market, while their number increased in the successful projects Smart, Training and partly App. Sponsors had a high, though temporary influence at decision points to ensure the next funding round. Functional experts were involved in later development phases (Smart, App) or in case of high uncertainty or necessary stakeholder management already from the beginning (Analytics, Training). In all projects, the operational progress is the responsibility of the core team, while responsibilities may shift after the implementation of the IP implementation (see e.g. Analytics).

All the concerned project managers and team members reported a high n overall level of satisfaction with the insights they gained. With respect to naviProM-Grid, all teams emphasized the new insight and high value of task execution mode switches depending on the specific levels of uncertainty. Thereby, they highlighted the added value of awareness creation for switching between different task execution modes as well as the pragmatic aid for making decisions about how and when to appropriately switch. The teams also appreciated to possibility to visualize their action patterns and compare the actually used versus the recommended ones. This practical added value perceived by the four IP teams was also confirmed by the members of the project teams I joined earlier, as well as internal and external colleagues to whom I presented the tool or who participated in a naviProM training. Some of their testimonials are summarized below:

"naviProM is my learning of the year", "naviProM is going to change the way I work with topic owners and the way I approach decision making in my own life. Very helpful!", "Wow! Really impressed with the model. Never thought this way", "naviProM is an eye-opening tool", "naviProM really helped me clearly define ideas I [´ve] have had before, concerning the approach. This reinforcement will help me make decisions faster and 142 more effectively!", "NaviProM was a huge 'aha' moment. (…) Really going to start 'executing' this knowledge. (…)."

With respect to naviProM-Flow, in particular App and Analytics appreciated the objective visualization that created the necessary transparency to identify main root-causes and potential sources of ongoing risks. Whereas all confirmed their willingness to continue applying the classification according to naviProM-Grid, the teams regretted the currently high effort required for using naviProM-Flow visualization features. This is partly due to the fact that providing a convenient software tool implementation was not part of the scope of my thesis.

The naviProM-Compass provided complementary information for identifying root causes. Its à posteriori application only helped to quantify context influence in retrospective. It, however, did not miss any relevant sources of context uncertainty. Thereby the team Analytics and Training confirmed that the prospective application of the tool would have helped to better capture the relevant context landscape. All teams agreed on the fact that applying the tool at the beginning and at the end of every substantial project phase, as well as at the occasion of substantial is very helpful. As far as the level of application is concerned, the added value of a per-task application is considered disproportionate to the effort required for doing it.

The naviProM-Net generated particular value in Analytics and Training that both involve large and diverse stakeholder networks. It created transparency about the network´s diversity, critical and weak links as well as actors. In Smart it confirmed the successful strategy to keep the network small and allowed identifying stakeholders that became or might become relevant in the future. The teams of these three projects emphasized that naviProM-Net allowed to systematically derive concrete actions. The App-team particularly highlighted the necessity of close team collaboration due to strict work scope assignments.

Globally speaking, the different naviProM elements provided value to every project, with a different special focus for each of them. While none of the teams would immediately apply all of elements at once, they all confirmed their willingness to continue applying and helping improve selected naviProM elements in their ongoing and future projects. From this experience, it can be stated that all the three hypotheses I set up in Section 6.1 (H1, H2, H3) have been confirmed. Furthermore, evaluating naviProM against the requirements derived in Section 6.2 in order to answer Q1 leads to the following results:

Conclusion

Against the background of an ever faster-changing social, ecological and economic environment that affects every industrial sector, this thesis proposes and investigates a methodology for conducting projects under conditions of heterogeneous and dynamically changing uncertainty. It also elaborates and validates a complementary set of tools that make the deployment of this methodology actionable in corporate organizations from small-to large-scale. Although managers of innovative projects within large, complex industrial organizations represent the original primary target group of these contributions, the results achieved can be useful for managers and team members of projects of any size and type.

The starting point of the thesis work was the elicitation of the fundamental requirements of innovation project management and decision aid tools that facilitate the successful implementation of any kind of projects characterized by a considerable level of uncertainty. The naviProM methodology is based on a project task model that integrates the definition of the input, targeted outcome, the action as well as the task's context and the stakeholder network involved (naviProM-Task). The essential assumption naviProM has been developed upon is the fact that the way a project task is to be managed and executed depends on the level of uncertainty associated with each task element. To take this assumption adequately into account, naviProM provides three different tools:

 naviProM-Grid is a two-dimensional model spanning the estimated uncertainty levels of a task's targeted outcome with respect to the inputs, as well as the task's actions. The two axes divide the space for potentially appropriate task execution modes into four areas: experiment, iterate, plan, and execute.

 In order to support naviProM users in estimating uncertainty levels in a quantitative, structured and traceable way, I designed naviProM-Compass. Based on the integration of three validated frameworks for characterizing uncertainty, context, and complexity, naviProM-Compass provides concrete, measurable parameters that capture the uncertainty of the two naviProM-Grid dimensions, as well as the task's context. I also proposed a generic formula linking results obtained from a naviProM-Compass to naviProM-Grid such that the result of applying both of them leads to a project task classification in terms of the task's recommended execution mode.

 naviProM-Net adds the stakeholder dimension to the analysis of project tasks. Rather than quantifying the uncertainty introduced by stakeholders, naviProM-Net builds on SNA concepts in order to facilitate the integration of key stakeholder roles, influences, attitudes, and relationships. naviProM-Net depicts project stakeholder networks as connected graphs that can evolve dynamically over time. This opens the door to the application of the huge set of graph metrics and algorithms to for computer-aided analysis of stakeholder networks that support project managers in establishing and continuously adjusting their project management and stakeholder involvement strategies. naviProM-Flow extends the widely adopted Gantt project plan notation by adding elements that graphically depict representing data obtained from the application of the above three tools. This means that through this work, project uncertainty, project context, as well as project stakeholders and their relationships, can be easily integrated into Gantt project plans and thereby guide project managers in taking these highly influential project influence factors into account frequently and systematically.

The entire methodology supports hierarchies, i.e., naviProM and its individual tools can be deployed on a project macro level as well as on the micro-level of work packages, tasks, and sub-tasks. In this deployment process, several decisions are subjective, e.g. the appropriate depth of project modeling and analysis, as well as the uncertainty parameter ratings. Therefore, naviProM cannot (and does not seek to) replace the decision makers in projects, but it can support them in a structured and traceable way.

I developed and validated naviProM in the context of four parallel, diverse and mutually independent innovation projects at the Bayer Group. These allowed me to combine findings from extensive literature analysis with numerous expert interviews, workshops and experience from real-world innovation projects. The experience collected there largely confirms all the hypotheses on which this work is based on. Furthermore, despite the challenging economic and political context, these projects gave me sufficient access to key stakeholders, data and information, as well as precious freedom and scope for designing, experimenting with and improving the methodology and tools I designed.

This deep rooting of my thesis work led to the tremendous success of naviProM at corporate level in the Bayer Group. I was asked to develop a naviProM-training to be published within a MOOC so as to facilitate its deployment on a broad scale. Furthermore, feedback I got from external researchers and experienced company experts at international conferences and workshops was very positive, encouraging me continue applying and enhancing naviProM beyond this thesis work.

Limitations

While the contributions this thesis makes to published literature in the areas related to project planning and management under uncertainty are numerous and strong thanks to their practical validation in a complex corporate environment, I can also see a lot of limitations to my work that I was unfortunately not able to address sufficiently well.

First of all, the context of this thesis demanded the research to be carried out in one specific company and industrial sector, which certainly limited validation to being carried out in this very environment. I tried to attenuate this limitation as much as possible, both by including only generic elements in naviProM and by reaching out to numerous external experts to whom I had access both within the company (consultants, coaches) and via scientific and practical conference communities (CIRP, EuroSPI).

More generally, validation in the domain of this thesis is a difficult, ambiguous and intrinsically limited subject, because unlike to processes, it is impossible  to compare any two projects, since every single project is unique;  to repeat a particular project so as to compare the impact of decisions made during this project;  to eliminate factors that influence the projects investigated, that are however out of the control for the researcher and sometimes even for the project managers themselves.

Consequently, expert advises and judgements had an important role also in the validation process of this thesis' contributions.

As for naviProM itself, I made the principal decision to keep the human expert at the center of any kind of project-related decisions. Although naviProM-Compass provides a framework for quantifying the uncertainty of any naviProM-Task elements, the quantification is still done by a human expert estimation and is therefore subjective. The method leaves open whether project managers do this estimation by themselves or in a more integrative approach, involving their teams or even external advisors in their decisions. Hence, I did objectify personal influence by e.g. capturing personal characteristics in the naviProM-Net or naviProM-Context. Further, in relation to the uncertainty quantification approach, I did not investigate mapping the uncertainty evaluation with naviProM-Compass to naviProM-Grid. Instead, I proposed the rather pragmatic method of applying the weighted mean of estimated uncertainty values to both naviProM-Grid axes, which also turned out to be actionable and useful in practice. Here too, however, project managers need to decide themselves about the weight factors they attribute to each uncertainty factor at any time during the project. This is far from straightforward, and undoubtedly requires experience in the application of the framework, as well as experimentation with adjusting both the formula and the weight factors. Another significant limitation related to this mapping is in the naviProM-Grid having only four discrete areas without "smooth" transitions. This means that based on the current method and tool design, a total uncertainty score of e.g. (2.1|2.1) would deliver the same result as e.g. (3.5|3.0) or even (4.0|4.0). It would be highly interesting to investigate whether and how zones of transition around the two naviProM axes could be specified so that naviProM provides better support to decision makersespecially in borderline situations. naviProM in its current form is limited to proposing a task execution mode only. While this was confirmed to be a significant contribution to existing project management methods and tools, it covers only one aspect of how to deal with uncertainty in projects. Furthermore, the question of when and how to switch execution modes remains largely unanswered and undoubtedly merits further investigation. Given the fact that making a project team successfully apply different methods such as Design Thinking, Scrum, Kanban, etc. requires special skills, infrastructure, and mindsets, the actual application of the naviProM advise to the project managers might not be straightforward and dependent on the specific organizational culture in which the project is embedded.

In order to deploy and investigate naviProM on a large scale, the developed tool elements would need to be integrated into existing project management tools. While this is considered straightforward to do for the task elements that can be analyzed in tables and displayed in naviProM-Flow, it is much less so for naviProM-Net, particularly when it comes to specifying and visualizing the dynamic evolution of stakeholder networks and their relationships with each other and with the tasks. In the bachelor thesis I supervised [START_REF] Peekhaus | Identifikation von Erfolgsfaktoren durch Visualisierung und Auswertung der Vernetzung sowie Interaktion in Innovationsnetzwerken[END_REF], we found that none of the almost 20 existing SNA tools we investigated fulfills all the requirements for making SNA actionable in typical corporate project contexts.

Perspectives

Based on the numerous limitations pointed out in Section 20, this thesis inspires a lot of potential for future research activities:

 Integration of naviProM in commonly used project management tools in order to make naviProM available on a large scale and gather both data and diverse expert feedback facilitating detailed analyses over the short/medium/long-term impact of naviProM application in various different projects. Such impacts should be investigated from various different perspectives: managerial, team-related, process-related, project flow and success, etc.

 Investigation of task patterns that are to be applied in particular project types and scenarios. Thanks to naviProM-driven task classification and visualization, it is possible to identify task sequences that have led to success in specific project situations and in particular contexts. naviProM could be extended to provide such sequences as a library of abstract models and patterns that can be instantiated and parameterized in individual projects. They could be used to suggest decisions for future project task planning, similarly to the process mining approach published in [START_REF] Es-Soufi | A Process Mining Based Approach to Support Decision Making[END_REF].

 Since naviProM can also capture context factors, on could even think about investigating and taking into account the context-dependency of task patterns in the abstract model library mentioned before. Such a decision aid would help going beyond the currently common "best practice" approach, which typically ignores contexts to judge if a practice applied in a particular project might actually be the best or not.

 Based on the extension above, naviProM could pro-actively suggest task patterns and required stakeholder roles given the task flow specification of the project at a given point of time. Collecting data from numerous projects over time would even enable the deployment of artificial intelligence methods such as CBR (Case Based Reasoning) and/or ML (Machine Learning) for enhancing naviProM with the ability to make suggestions for planning the future course of a project.

 The question when to apply and re-apply naviProM to a project and its sub-projects, as well as at what level should also be further investigated.

Throughout the project duration, project managers wonder when the right time is to re-evaluate tasks based on the project planning. They also want to know at which level of planning detail they should stop applying naviProM.

 Furthermore, best ways of switching between different task execution modes should be investigated. This subject is complex, since it is linked with many different influencing factors such as organizational culture, capabilities, experiences, leadership behavior, etc.

 naviProM-Grid is currently a discrete model with sharp limits separating the four quadrants denoting recommended task execution modes. As we have already seen in the projects we investigated, these discrete boundaries provided limited value to decision makers especially in situations where naviProM evaluation leads to results located very closely to these boundaries. One could think about smooth transitions by applying e.g. Fuzzy Logic, with fuzzy membership functions determined from empirical and experimental data collected from several different projects.

 naviProM-Flow as visualization tool certainly inspires about many different extensions that could be researched. First of all, a convenient way of integrating data derived from the entire tool set should be investigated. For this to happen, different views could be adopted directing their focus on e.g. stakeholders, tasks, context, particular phases and work package/task abstraction levels. Furthermore, linking these different views in a way they can provide maximum added value and usability to users is a subject worthwhile investigating further.

 naviProM-Net currently explores only a very limited set of SNA concepts. This could be greatly extended so that it becomes possible for project managers to develop stakeholder strategies visually and interactively and evaluate different scenarios. This could be done not only statically, but also dynamically such that the SNA representation is synchronized with the most up-to-date data about the social network relationships of direct and indirect project stakeholders.

Figure 1 - 1 :

 11 Figure 1-1: Structure of the thesis ......................................................................

Figure 7 - 1 :

 71 Figure 7-1: Organizational structure Bayer Group ............................................

Figure 7 - 2 :

 72 Figure 7-2: Research methodology ....................................................................

Figure 8

 8 Figure 8-1: naviProM-Task task model .............................................................

Figure 9

 9 Figure9-1: naviProM-Grid(Gebhardt et al. 2018; Gebhardt et al. 2019a) .......

Figure 10 - 1 :

 101 Figure 10-1: Context scheme (Hales and Gooch 2004) .....................................

Figure 10 - 2 :

 102 Figure 10-2: Entropy compass (Breitschuh et al. 2018, p. 7) ............................

Figure 10 - 3 :

 103 Figure 10-3: Complexity Framework (Rezende and Blackwell 2019, p. 137) ..

Figure 10 - 4 :

 104 Figure 10-4: Uncertainty Kaleidoscope (Saunders et al. 2016, p. 1063) ...........

Figure 10

 10 Figure 10-5: Context-Complexity-Uncertainty-triangle ....................................

Figure 10

 10 Figure 10-6: naviProM-Compass .......................................................................

Figure 10

 10 Figure 10-7: Example: naviProM-Compass ......................................................

Figure 11 - 1 :

 111 Figure 11-1: Roles throughout the project life cycle (Markham et al. 2010) ....

Figure 11 - 2 :

 112 Figure 11-2: Stakeholder roles (Gebhardt et al. 2019b).....................................

Figure 11 - 3 :

 113 Figure 11-3: Stakeholder attitude and influence (Gebhardt et al. 2019b) ..........

Figure 11 - 4 :

 114 Figure 11-4: Sample network ............................................................................

Figure 12 - 1 :

 121 Figure 12-1: Task classification, outcome, relation & stakeholder influence ....

Figure 13 - 1 :

 131 Figure 13-1: Research´ timeline.........................................................................

Figure 13 - 2 :

 132 Figure 13-2: Grounded field research design in several design cycles ..............

Figure 14 -

 14 Figure 14-1: naviProM-Flow retrospective analysis -Project Smart ................

Figure 14 -

 14 Figure 14-2: naviProM-Compass -Project Smart .............................................

Figure 14 -

 14 Figure 14-3: naviProM-Net -Project Smart ......................................................

Figure 15 -

 15 Figure 15-1: naviProM-Flow -Project Analytics ............................................

Figure 15

 15 Figure 15-2: naviProM-Compassproject Analytics ......................................

Figure 15

 15 Figure 15-3: naviProM-Net phase 1 -Project Analytics .................................

Figure 15

 15 Figure 15-4: naviProM-Net phase 3 -Project Analytics .................................

Figure 16

 16 Figure 16-1: naviProM-Flow -Project App ....................................................

Figure 16

 16 Figure 16-2: naviProM-Compass -Project App ..............................................

Figure 16

 16 Figure 16-3: naviProM-Net phase 1 -Project App ..........................................

Figure 16

 16 Figure 16-4: naviProM-Net phase 3 -Project App ..........................................

Figure 17

 17 Figure 17-1: Global-level WBS -Project Training .........................................

Figure 17

 17 Figure 17-2: naviProM-Flow phase 0,1 -Project Training .............................

Figure 17

 17 Figure 17-3: naviProM-Flow phase 0,1,2 -Project Training ..........................

Figure 17

 17 Figure 17-4: naviProM-Flow -Project Training .............................................

Figure 17

 17 Figure 17-5: naviProM-Compassproject Training .......................................

Figure 17

 17 Figure 17-6: naviProM-Net phase 1 -Project Training ...................................

Figure 17

 17 Figure 17-7: naviProM-Net phase 3 -Project Training ...................................

Figure

  Figure 1-1: Structure of the thesis

Figure 7 - 1 :

 71 Figure 7-1: Organizational structure Bayer Group

Figure

  Figure 7-2: Research methodology

Figure 8

 8 Figure 8-1: naviProM-Task task model

Figure 10

 10 Figure 10-1: Context scheme (Hales and Gooch 2004)More recent models such as[START_REF] Snowden | A leader's framework for decision making[END_REF] and[START_REF] Wilmsen | A context-model for adapting design processes and methods[END_REF] also capture system uncertainty, integrating micro and macro levels derived from an extensive literature analysis in product development and design management, project management, general management, organization theory, and psychology. However, these are theoretical non-validated design concepts and vulnerable to subjective biases. In particular they are lacking practicality due to their high number of factors that have to be evaluated with regard to measurability, dynamics, interdependencies as well as relevance[START_REF] Gericke | Understanding the context of product development[END_REF] or their individual frequency of change throughout the project[START_REF] Wilmsen | A context-model for adapting design processes and methods[END_REF].[START_REF] Shenhar | Reinventing Project Management. The Diamond Approach To Successful Growth And Innovation[END_REF] and[START_REF] Rezende | Revisiting project complexity: a new dimension and framework[END_REF] focus on project complexity, while[START_REF] Rosenberger | Context-awareness in industrial applications: definition, classification and use case[END_REF] propose a context classification framework for context-aware design of industrial applications, though not taking into account the relationship of context to the design project and process.These frameworks constitute uncertainty and complexity as central and influencing elements of context. I, therefore, postulate that frameworks capturing project's uncertainty or complexity, integrate both project internal (micro level) complexity and/ or uncertainty and a project's environmental (macro level) complexity and/or uncertainty. This would address the still lacking requirement of practicability. Hence, an integrated model considers the fact, that a project has to be actively adapted to its context, and that the project affects the context[START_REF] Gericke | Understanding the context of product development[END_REF].Recent scientific frameworks considering uncertainty or complexity are for instance,[START_REF] Breitschuh | Scaling agile practices on different time scopes for complex problem solving[END_REF]. The authors developed the Entropy-Compass in order to capture project complexity as a dynamic system property (see Figure10-2). Therefore, the authors combine the established schemes of[START_REF] Hales | Managing Engineering Design[END_REF] and the complexity dimensions of VUCA (Volatility, Uncertainty,

Figure 10

 10 Figure 10-2: Entropy compass (Breitschuh et al. 2018, p. 7) Rezende and Blackwell (2019) propose a complexity framework for capturing project complexity (Figure10-3). It is based on a systematic and extensive literature research related to "project complexity". At the top level, the framework differentiates between structural complexity, uncertainty, pace, novelty, dynamic social-political, and institutional dimension, which were further specified in ten subdimensions. Despite a rating scale, the framework is not a measurement tool, but is designed to enrich discussions about a project's complexity throughout its life cycle.

Figure 10

 10 Figure 10-3: Complexity Framework (Rezende and Blackwell 2019, p. 137)[START_REF] Saunders | Conceptualising uncertainty in safety-critical projects: A practitioner perspective[END_REF] propose an Uncertainty Kaleidoscope (Figure10-4), which conceptualizes and validates the determinants of uncertainty in the context of safety-critical projects[START_REF] Saunders | Mapping the multi-faceted. Determinants of uncertainty in safety-critical projects[END_REF]. Thereby, the Kaleidoscope has no guidance purpose, but rather provides a validated visualization model, enabling founded discussions about potential sources of uncertainty in the context of safety-critical use-cases during a project's life cycle.

Figure 10

 10 Figure 10-5: Context-Complexity-Uncertainty-triangle

Figure 10

 10 Figure 10-6: naviProM-Compass

  2. Determine the weighting of Information, and Complexity, and Context for both UO and UA. 3. Rate the individual Information and Complexity parameters. 4. Rate the individual Context parameters determining the context as a whole for both UO and UA. 5. Determine Information and Complexity by calculating the weighted average of the individual parameter ratings. 6. Determine Context by calculating the weighted average of the individual parameter ratings. 7. Reapply this procedure throughout the project in case of any significant changes in the project structure or the context.

  differentiate different skills, assuming that role profiles are subject to individual characteristics or overlap with other roles. Although, e.g.[START_REF] Markham | The Valley of Death as Context for Role Theory in Product Innovation[END_REF] tried to generalize roles and their relevance in specific process activities (see Figure11-1)(Dedehayir et al. 2016;[START_REF] Roth | Stakeholder integration in service innovationan exploratory case study in the healthcare industry[END_REF], it is acknowledged that roles and networks are both project-and context-specific[START_REF] Kelley | Intra-organizational networking for innovation-based corporate entrepreneurship[END_REF][START_REF] Tushman | Organizing for Innovation[END_REF][START_REF] Gurtner | From roles to skillskey persons in the innovation process[END_REF].

Figure 11

 11 Figure 11-1: Roles throughout the project life cycle[START_REF] Markham | The Valley of Death as Context for Role Theory in Product Innovation[END_REF]

Figure 11 -

 11 Figure 11-2 shows the different roles (1-6) represented as nodes in the naviProM-Net. A red dotted framed node makes it possible to differentiate between internal and external network actors.

Figure 11

 11 Figure 11-2: Stakeholder roles (Gebhardt et al. 2019b)

Figure 11

 11 Figure 11-3: Stakeholder attitude and influence(Gebhardt et al. 2019b)

Figure

  Figure 11-4: Sample network

Figure 12

 12 Figure 12-1: Task classification, outcome, relation & stakeholder influence

Figure

  Figure 13-1: Research´ timeline.

Figure 13

 13 Figure 13-2: Grounded field research design in several design cycles

Figure 14 -

 14 Figure 14-1: naviProM-Flow retrospective analysis -Project Smart

Figure 14 -

 14 Figure 14-2 shows the naviProM-Compass of Smart, illustrating context influence with respect to UO and UA.

Figure 14 -

 14 Figure 14-2: naviProM-Compass -Project Smart

Figure 14 -

 14 Figure 14-3: naviProM-Net -Project Smart

Figure 15

 15 Figure 15-1: naviProM-Flow -Project Analytics

Figure 15

 15 Figure 15-3: naviProM-Net phase 1 -Project Analytics

Figure 15

 15 Figure 15-4: naviProM-Net phase 3 -Project Analytics

Figure 16

 16 Figure 16-1: naviProM-Flow -Project App

Figure 16

 16 Figure 16-3: naviProM-Net phase 1 -Project App

Figure 16

 16 Figure 16-4: naviProM-Net phase 3 -Project App

Figure 17

 17 Figure 17-1: Global-level WBS -Project Training

  Figure 17-2: naviProM-Flow phase 0,1 -Project Training

Figure 17

 17 Figure 17-3: naviProM-Flow phase 0,1,2 -Project Training

  Figure 17-4: naviProM-Flow -Project Training

Figure 17

 17 Figure 17-5: naviProM-Compassproject Training

Figure 17

 17 Figure 17-6: naviProM-Net phase 1 -Project Training

Figure 17

 17 Figure 17-7: naviProM-Net phase 3 -Project Training

Table 6 -

 6 1: Requirements (1/2) ...........................................................................

Table 6-2: Requirements (2/2) ........................................................................... Table 8-1: naviProM-Task element analysis .....................................................

Table 9-1: Example: naviProM-Task in experimentation.................................. Table 9-2: Example

: naviProM-Task in iteration .............................................. Table 9-3: Example: naviProM-Task in plan ..................................................... Table 9-4: Example: naviProM-Task in execution ............................................ Table 9-5: naviProM-Task evaluation based on naviProM-Grid ....................... Table 10-1: Complexity -Uncertainty parameter framework mapping............. Table 10-2: Example: parameter evaluation ......................................................

Table 14-1: naviProM-Flow documentation -Project Smart ............................ Table 14-2: naviProM-Compass evaluation -Project Smart ............................. Table 14-3: naviProM-Grid including naviProM-Compass -Project Smart ..... Table 15-1: naviProM Compass evaluation -Project Analytics ...................... Table 16-1: naviProM Compass evaluation -Project App .............................. Table 17-1: Flow evaluation phase 1,2 -Project Training .............................. Table 17-2: Flow evaluation phase 3 -Project Training ................................. Table 17-3: naviProM-Compass evaluation -Project Training ......................

Table 18 -

 18 1: Comparison of Case Study projects ............................................. Table 18-2: Requirements vs. Results .............................................................Table 21-1: Questionnaire (1/2) to validate naviProM-Compass .................... Table 21-2: Questionnaire (2/2) to validate naviProM-Compass ....................

Table 6

 6

	ID	Requirement	Short-
			comings
	RQ1 To model a project based on tasks and task flows embedded in	S1
		their context.
	RQ2 To relate individual tasks with uncertainty.	S4, S5
	RQ3 To systematically capture the task context.	S1
	RQ4 To identify sources of uncertainty.	S4
	RQ5 To capture the stakeholders influencing tasks.	S3
	RQ6 To capture the interdependencies of tasks.	S2
	RQ7 To capture the interdependencies of stakeholders.	S3
	RQ8 To capture the dynamics and life cycle of each task or task flow. S1
		-2: Requirements (2/2)
	RQ9 To capture different focus views on the project structure down to
		the task level.
	RQ10 To provide a high level of usability.

Part II: Development of the naviProM Method and Tool Set 7 Conceptual Framework of the Research 7.1 Research question

	Based on the research gap and requirements identified in Part I, I phrase my
	central research questions as follows:

  :

	o User acceptance
	o Financing/ Funding
	o Stakeholder alignment
	 Desirability:
	o Definition of needs and target group
	o Understanding and validation of needs and target group
	 Feasibility:
	o Invent & validate the solution
	o Develop solution
	 Viability

naviProM Outcome 10 Context Uncertainty 10.1 Context uncertainty frameworks

		Phase	Task ID Task name Input	Targeted outcome	U Action U	R	A	OE
	1	Problem understanding	1 1.1	Understand customer Understand customer needs	Market research Market research; specified customer	Specified customer Specified customer needs	+ Observe potential customer + Observe specified customer	+ + + Specified customer + + + Specified customer needs	+ +

Table 10

 10

-1.

Table 10 -

 10 1: Complexity -Uncertainty parameter framework mapping

	Kaleidoscope		Entropy	Triangle	Sample project aspects
	Environment	Institutional	Definition and agreement	Context	Resource availability, regulatory constraints, processes, etc.
	Environment	Political	Definition and agreement	Context	Strategy, influence, interests, governance, funding, etc.
					Organizational culture,
	Environment	Social	Definition and agreement	Context	stakeholder values/demands, stakeholder performance
					predictability/qualification, etc.
					Emergent issues/influences,
	Dynamics	Dynamics	n/a	Context	changing requirements, changing
					stakeholders, etc.
					New solutions, technologies,
	Complexity	Novelty	Strurctural comlexity		concepts; new team compositions and
					interrelationships, etc.
					Time/seasonal dependencies, life
	Time	Criticality	Pace	Context	cycle stage/phase, task
					interdependencies, etc.
					Pace of progress, task
	Time	Speed	Pace	Context	synchronisation, innovation cycle
					duration, etc.
	Information	Uncertainty	Availability of knowledge and transparency	Uncertainty	Unclear/fuzzy/ambiguous needs/requirements, unclear problem understanding/definition, etc.
	Complexity	Interde-pendence	Structural complexity	Complexity	Interdependence of tasks, needs/requirements, solution approaches, stakeholders, etc.
					Number, size and diversity of
	Complexity	Size/Variety	Structural complexity	Complexity	tasks, needs/requirements, solution approaches,
					stakeholders, etc.
					Number and diversity of
	Capability	n/a	n/a	Context	qualifications, expertise domains,
					sectors, experience levels, etc.
					Personal interests, attitudes,
	Individual	n/a	n/a	Context	values, bias, risk-taking,
					venturesome, etc.

  The Novelty parameter describes how new the project's aspects are in terms of 1derivative or 4-new to the world (e.g. new context, need, mission, technology, process, stakeholder). 2. The Complexity cluster includes Size/Variety and Interdependence. Size/Variety describes the number and diversity of e.g. actors, organizational units, resources and potential approaches, while Interdependence defines the impact of actors, organizational units, tasks and potential approaches as well as the knowledge about their impact. 3. Capability defines the level of available or accessible skills and expertise. 4. The Environmental cluster consists of the Social, Political, and Institutional dimension: Social describes the influence of organizational culture, stakeholder demands and communication; Political parameter includes competition, strategic pressure, and required local requirements;

Table 10 -

 10 2 shows an example, in which context, Information, and Complexity are all weighted with one (see "Weight"columns, grey rows). Further, individual parameters are weighted as follows: In case of UO, Social, Political and Dynamics are weighted with 4, and all other parameters with 1. In case of UA, all parameters are weighted with 1. The columns "Value" show the individual evaluation of each parameter.Thus, the value of UO isonly based on Information parameterslow (2.0), while the value of UA isonly based on Complexity parametershigh (4.0) (see grey rows). By contrast, Context in UO (3.41) is assessed as high, while Context in UA (2.5) is high, however bordering on low in UA. Therefore, naviProM recommends experimentation as the overall assessments of UO (2.71) and UA (3.25) are both high, when considering the Context. A general rate and recurrent assessment of actual disposition make it possible to systematically detect where uncertainty may arise and to capture uncertainty comprehensively with respect to UA and UO. Table 10-2: Example: parameter evaluationFigure 10-7 visualizes the example within the naviProM-Compass. The inner network diagram includes the score (1 to 4) of each parameter. The node's size represents its weight. The green nodes represent only UO related context parameters. The dark blue nodes represent only UA related context parameters, while the green blue-edged nodes represent context parameters in which UO and UA have the same score.Here the naviProM-Compass, for instance, illustrates the high influence of context on UO. It makes it possible to quickly capture the high weightings and values of Political, Social and Dynamics. In UO context has low influence, but the parameter Capabilities. In case of UA, the dark blue nodes highlight the high influence of Complexity.

	UO			UA
	Parameter Weight	Value	Parameter Weight	Value
	Ambiguity	1	2 -2 -Ambiguous	Size/Variety	1	4 + 4 -Very large/diversed
	Novelty	1	2 -2 -New to the organization	Interde-pendence	1	4 + 4 -High interdependence
	Information	1	2.00 -	Complexity	1	4.00 +
	Context UO			Context UA
	Parameter Weight	Value	Parameter Weight	Value
	Capabilities	1	2 -2 -Mostly skilled	Capabilities	1	4 + 4 -Not skilled
	Institutional	1	2 -2 -Few constraints	Institutional	1	2 -2 -Few constraints
	Political	4	4 + 4 -Opposite	Political	1	2 -2 -Slightly supportive
	Social	4	4 + 4 -Intractable	Social	1	1 -1 -Collaborative
	Criticality	1	2 -2 -Moderate	Criticality	1	3 + 3 -High
	Speed	1	2 -2 -Regular	Speed	1	4 + 4 -Time critical
	Dynamics	4	4 + 4 -Chaotic/very unstable	Dynamics	1	2 -2 -Ordered/few instabilities
	Individual	1	2 -2 -Neutral	Individual	1	2 -2 -Neutral
	Context	1	3.41 +	Context	1	2.50 +
	UO		2.71 +	UA		3.25 +

73 Figure 10-7: Example: naviProM-Compass

Table 14

 14

	-1: naviProM-Flow documentation -Project Smart

Table 14

 14

			-3: naviProM-Grid including naviProM-Compass -Project Smart
	Phase Task ID	Task name	Novelty Ambi-	UO	Size/	Inter-	UA	navi	OE
						guity		Variety	depen-		ProM
							Grid Compass		dence	Grid Compass	R A
	1.	Understanding & solution concept exploration	1 1.1 1.1.1 1.1.1.1-3 HW test I,II,III Structure understanding Validate problem (V1) Explore HW design 1.1.2 Explore SW design 1.1.2.1-3 SW test I,II,III 1.1.3 Intellectual property protection 1.2 Solution development (V2)	2 3 3 3 3 3 1 3	2 2 3 3 3 3 1 4	2.0 -2.13 -2.5 + 2.38 -3.0 + 2.63 + 3.0 + 2.63 + 3.0 + 2.63 + 3.0 + 2.63 + 1.0 -1.63 -3.5 + 2.88 +	4 3 3 2 4 3 1 1	4 4 4 3 4 4 1 3	4.0 + 3.13 + 3.5 + 2.88 + 3.5 + 2.88 + 3.0 + 2.63 + 4.0 + 3.13 + 3.0 + 2.63 + 1.0 -1.63 -2.0 -2.13 -	P P + P X + X X + X X + X X + X X + E E + I I !
	2.		2	Structure	2	2	2.0 -2.13 -	4	4	4.0 + 3.13 +	P P +
		Concept design	2.1 2.2 2.3	development (V1) Get funding Develop HW (V1) Develop SW (V1)	3 3 3	2 3 3	2.5 + 2.38 -3.0 + 2.63 + 3.0 + 2.63 +	1 2 2	1 2 2	1.0 -1.63 -2.0 -2.13 -2.0 -2.13 -	E E + I I + I I +

Table 16 -

 16 1: naviProM Compass evaluation -Project App

	Factor	Weight		Factor	Weight
	Ambiguity	1	3 + 3 -Very ambiguous	Size/Variety	1	3 + 3 -Large/high diversity
	Novelty	1	3 + 3 -New to the market	Interde-pendence	1	3 + 3 -Medium interdependence
	Information	1	3.00 +	Complexity	1	3.00 +
	Factor	Weight		Factor	Weight
	Capabilities	1	2 -2 -Mostly skilled	Capabilities

Table 17

 17

	-1: Flow evaluation phase 1,2 -Project Training
	A
	R

Table 17 -

 17 3: naviProM-Compass evaluation -Project Training

Table 18 -

 18 1: Comparison of Case Study projects

Table 18 -

 18 2: Requirements vs. ResultsTable18-2 shows that RQ1-RQ9 are covered by naviProM, while RQ10 is not. Clearly, any coverage figure is far from being complete, as will be pointed out in the subsequent Section 20 and Section 20. Net RQ6 To capture the interdependencies of tasks.naviProM-Flow RQ7 To capture the interdependencies of stakeholders. naviProM-Net RQ8 To capture the dynamics and life cycle of each task or task flow.

	ID	Requirement	Results
	RQ1 To model a project based on tasks and task flows	naviProM-Task/Flow
		embedded in their context.
	RQ2 To relate individual tasks with uncertainty.	naviProM-Grid
	RQ3 To systematically capture the task context.	naviProM-Compass
			(naviProm-Net: stakeholder
			dimension of the context)
	RQ4 To identify sources of uncertainty.	naviProM-Compass
	RQ5 To capture the stakeholders influencing tasks.	naviProM-Flow/-naviProM-Flow
	RQ9 To capture different focus views on the project	naviProM-Flow/-Net
		structure down to the task level.
	RQ10 To provide a high level of usability.	Only partly achieved in
			naviProM-Net, because
			professional tool
			implementation was not in the
			research project scope.

naviProM-Net: Stakeholder Analysis

Acknowledgements

Part III: Industrial Case Studies