# An Assistance to Project Risk Management Based on Complex Systems Theory and Agile Project Management

Authors: Franck Marle
Journal: Complexity
 (2020)

---

## Abstract

Project Risk Management is crucial in determining the future performance of a complex project. Increasing project complexity makes it more and more difficult to anticipate potential events that could affect the project and to make effective decisions to reduce project risk exposure. To tackle these conceptual and managerial issues, the proposed approach introduces Complex Systems Theory-based improvements into some PRM subprocesses and runs the global PRM process using Agile Project Management principles. We argue that these advanced techniques for managing project risk complexity, notably risk interdependencies, are coherent with the distributed, self-organized nature of agile teams. This new way of structuring and executing Project Risk Management offers the possibility to make decisions more frequently, when needed, with a more distributed authority, and with richer information about anticipation of events and consequences of actions. First results show an appropriation of this combined approach by project members due to agile principles that allows for getting the more reliable information promised by Complex Systems Theory.


---

## Body

## 1. Introduction

Project Risk Management (PRM) is the process of managing potential events that could affect, positively or negatively, project activities and project objectives [1, 2]. Current PRM concepts and methods are not enough to face complexity-induced stakes [3]. Unplanned events or changes due to the complex nature of the risks are inevitable and have a positive correlation with unsuccessful projects if not correctly managed [4]. It has also been shown that actual Project Risk Management practices in agile contexts but without conceptual assistance did not correspond to recommended methodologies and expected results [5]. Two issues are thus of particular interest, respectively, conceptual and managerial limits of existing PRM methodologies. These issues are all the more important since PRM performance is crucial for the performance of the projects and the organizations that support them [6–9].This is why PRM needs to be adapted in order to integrate advanced complexity-related and alternative management principles. This adaptation will help to increase capacity of prediction, coordination, decision, and action under complex and risky contexts. Our aim is thus to assist the management of project risks by building a hybrid approach, combining Complex Systems Theory (CST) and Agile Project Management (APM).The remainder of the paper is as follows. Section2 introduces project complexity, its consequences, and PRM limits facing it. Section 3 presents the research approach. Section 4 briefly introduces the structure of the approach, where CST-based principles are encapsulated into PRM subprocesses, embedded into agile management steps. The upgraded PRM process will be detailed in Sections 5–9, corresponding to classical agile steps and PRM subprocesses, upgraded with CST-based principles, concepts, methods, and tools. An illustrating example will be developed all along these sections. Then, Sections 10 and 11 will draw some elements of discussion, conclusion, and perspective.


## 2. Research Question

This section introduces project complexity and its consequences and then Project Risk Management processes and their conceptual and managerial issues facing this complexity.


### 2.1. Project Complexity and Its Consequences

Complexity of systems, and notably projects, has been studied for decades, in different fields and with different aims [10–12]. Project complexity can be a source of different phenomena [13–16]: ambiguity, uncertainty, propagation, and even chaos. Different concepts have been defined for project complexity; however, they all recognize the necessity to consider interdependencies between the diverse and numerous components of the project system [17].However, the classical hierarchy-based or pyramid-based management has involved a global, separated vision of risks. Since the underlying philosophy is centralized decision and command-and-control, things are split into cells so that decisions can be made about these cells. However, local decisions may have nonlinear consequences on the rest of the project, either for other stakeholders or for other phases of the project [18]. A cost saving of 10 in the design phase may involve an over cost of 1000 in the construction phase or 10 000 in the maintenance phase.Project complexity has also a consequence on how things need to be managed and can be managed. De Toni and Pessot showed that a higher complexity level necessitates activating different team behaviors and organizations modes, implying the necessity to use a flexible, adaptable mode [19]. Moreover, Maqsoom et al. found a positive correlation between a high complexity risk and the reduction of managerial control [20]. The point where project complexity has overwhelmed the capacity of managing has been one of the reasons of emergence of alternative management principles, like agility, which favored dynamic, iterative, flexible, incremental, and user-centric development [21].The next paragraph briefly introduces generic PRM subprocesses and their limits facing project complexity.


### 2.2. Conceptual and Managerial Issues of PRM Facing Complexity

Global PRM process consists of several iterative steps: risk management principles definition, risk identification, risk assessment, risk analysis, risk response planning (or treatment), risk monitoring and control, and lessons learnt [1, 2, 22].


#### 2.2.1. Definition of Risk Management Principles

This initialization step consists in defining management of Project Risk Management, in which methods, tools, and techniques will be used. However, it generally does not give any idea about the management style, about the level of centralization/decentralization for data gathering, estimation, and authority in decision-making.


#### 2.2.2. Risk Identification

It is aimed at listing potential events that could impact, positively or negatively, project activities and objectives. Numerous techniques have been developed in different fields and transposed to Project Risk Management, classified by [23] in analogical [24–27], heuristics-based [28, 29], and analytical methods [30–35]. These methods also theoretically enable opportunities, positive risks, to be included [36, 37]. However, classical methods (even trees or Bayesian networks) are not enough to capture the overall project complexity, for instance, loops. The way actors are organized and behave may also have an impact on risk identification [38].


#### 2.2.3. Risk Assessment

It consists in putting qualitative or quantitative estimates to risks, according to several parameters [39–41]. However, it is generally based on only two indicators, probability (or likelihood) and impact (or gravity). Moreover, the assessment of a risk may be different if made by different actors, depending on their role, relation to the risk, and personality.


#### 2.2.4. Risk Analysis

It consists in prioritizing risks according to one parameter or a combination of parameters. Classical analysis is often based on combination of probability and impact, either by using a probability-impact diagram or by multiplying both terms to get what is called risk criticality [42]. This involves compensation: two risks, respectively, with (P=1; I = 5) and (P=5; I = 1), will have the same criticality value, albeit they are completely different. Some works have been done to improve this, by reconsidering these diagrams [43–45]. Moreover, when risks are modeled as if they were independent (in a single Excel column for instance), it is impossible to properly assess indirect complexity consequences. Second, it is sometimes a single person who runs the analysis of every risk, either the project manager, the risk manager, or the risk analyst. This involves a clear issue of competence, individual bias, and versatility.


#### 2.2.5. Risk Response Planning

It is the process of selecting actions to reduce global risk exposure at minimal cost. The aim is to dispatch available resources, depending on risk criticality and action characteristics (impact and cost) [46]. Different methods exist: zonal-based method, studying actions for different zones of two-axis diagrams [47], WBS-based method [48], linking actions to WBS elements [48], tradeoff method, seeking for one objective while keeping another one under control [49], and optimization-based method [49, 50]. However, the indirect impact or secondary effects of actions are not considered, resulting in undesired impacts like medication. Moreover, actions are generally considered as independent, meaning that no analysis is made about their potential connections, like synergies or cannibalizations.


#### 2.2.6. Risk Monitoring and Control

The main issues of this phase are the way decisions are made (especially in a hierarchy-based management), the rhythm of monitoring and control, and the autonomy that members have in the interval between two risk review meetings.


#### 2.2.7. Lessons Learnt

It is generally done at the end of the project, preventing the continual injection of experience all along the project. Second, there may be a huge time interval between the moment things happen and the moment experience is captured, with a possibility of forgetting or being less precise. Third, there may be a risk of blame assigning that may prevent members for journaling what really happened.


### 2.3. Research Question

This research work started with two types of industrial relationships. First, we have companies with whom previous research projects had been carried out in order to introduce CST principles in PRM. Conceptual gains were recognized, albeit there were issues about implementation and practical appropriation. Indeed, the way projects were managed, with hierarchy and command-and-control philosophy, prevented this CST-based PRM process to be undertaken with a network of actors. There was a gap between the potential of actors’ coordination and the reality, still centralized. The problem here was thus to introduce alternative management principles into a global, hybrid PRM approach, combining CST and agile principles. Second, companies running their projects with agile principles declared a lack of consideration of PRM. It was because of a lack of reliability of risk management results (analysis and response plans). It is because PRM did not work well that project members used their autonomy to put it at a lower priority level. The problem here is to introduce conceptual improvements into PRM.As shown in Figure1, there are three possible initial situations. In our research work, we ran first introduction of CST-based principles into PRM (arrow 1) and then introduction of APM into the CST-based upgraded PRM process (arrow 2). The second path, which is for us a perspective, is to introduce CST principles into an APM-based organization for managing its risks (arrows 3 and 4). However, for reading convenience and presentation of a generic case, the paper is organized according to arrow 5 of Figure 1, simulating the combined process.Figure 1
Illustration of the diagram of possible paths towards combination of CST and APM into PRM.In order to be as generic as possible, we formulate our research question as follows: how to face complexity, both on its conceptual and managerial aspects, while managing project risks?


## 2.1. Project Complexity and Its Consequences

Complexity of systems, and notably projects, has been studied for decades, in different fields and with different aims [10–12]. Project complexity can be a source of different phenomena [13–16]: ambiguity, uncertainty, propagation, and even chaos. Different concepts have been defined for project complexity; however, they all recognize the necessity to consider interdependencies between the diverse and numerous components of the project system [17].However, the classical hierarchy-based or pyramid-based management has involved a global, separated vision of risks. Since the underlying philosophy is centralized decision and command-and-control, things are split into cells so that decisions can be made about these cells. However, local decisions may have nonlinear consequences on the rest of the project, either for other stakeholders or for other phases of the project [18]. A cost saving of 10 in the design phase may involve an over cost of 1000 in the construction phase or 10 000 in the maintenance phase.Project complexity has also a consequence on how things need to be managed and can be managed. De Toni and Pessot showed that a higher complexity level necessitates activating different team behaviors and organizations modes, implying the necessity to use a flexible, adaptable mode [19]. Moreover, Maqsoom et al. found a positive correlation between a high complexity risk and the reduction of managerial control [20]. The point where project complexity has overwhelmed the capacity of managing has been one of the reasons of emergence of alternative management principles, like agility, which favored dynamic, iterative, flexible, incremental, and user-centric development [21].The next paragraph briefly introduces generic PRM subprocesses and their limits facing project complexity.


## 2.2. Conceptual and Managerial Issues of PRM Facing Complexity

Global PRM process consists of several iterative steps: risk management principles definition, risk identification, risk assessment, risk analysis, risk response planning (or treatment), risk monitoring and control, and lessons learnt [1, 2, 22].


### 2.2.1. Definition of Risk Management Principles

This initialization step consists in defining management of Project Risk Management, in which methods, tools, and techniques will be used. However, it generally does not give any idea about the management style, about the level of centralization/decentralization for data gathering, estimation, and authority in decision-making.


### 2.2.2. Risk Identification

It is aimed at listing potential events that could impact, positively or negatively, project activities and objectives. Numerous techniques have been developed in different fields and transposed to Project Risk Management, classified by [23] in analogical [24–27], heuristics-based [28, 29], and analytical methods [30–35]. These methods also theoretically enable opportunities, positive risks, to be included [36, 37]. However, classical methods (even trees or Bayesian networks) are not enough to capture the overall project complexity, for instance, loops. The way actors are organized and behave may also have an impact on risk identification [38].


### 2.2.3. Risk Assessment

It consists in putting qualitative or quantitative estimates to risks, according to several parameters [39–41]. However, it is generally based on only two indicators, probability (or likelihood) and impact (or gravity). Moreover, the assessment of a risk may be different if made by different actors, depending on their role, relation to the risk, and personality.


### 2.2.4. Risk Analysis

It consists in prioritizing risks according to one parameter or a combination of parameters. Classical analysis is often based on combination of probability and impact, either by using a probability-impact diagram or by multiplying both terms to get what is called risk criticality [42]. This involves compensation: two risks, respectively, with (P=1; I = 5) and (P=5; I = 1), will have the same criticality value, albeit they are completely different. Some works have been done to improve this, by reconsidering these diagrams [43–45]. Moreover, when risks are modeled as if they were independent (in a single Excel column for instance), it is impossible to properly assess indirect complexity consequences. Second, it is sometimes a single person who runs the analysis of every risk, either the project manager, the risk manager, or the risk analyst. This involves a clear issue of competence, individual bias, and versatility.


### 2.2.5. Risk Response Planning

It is the process of selecting actions to reduce global risk exposure at minimal cost. The aim is to dispatch available resources, depending on risk criticality and action characteristics (impact and cost) [46]. Different methods exist: zonal-based method, studying actions for different zones of two-axis diagrams [47], WBS-based method [48], linking actions to WBS elements [48], tradeoff method, seeking for one objective while keeping another one under control [49], and optimization-based method [49, 50]. However, the indirect impact or secondary effects of actions are not considered, resulting in undesired impacts like medication. Moreover, actions are generally considered as independent, meaning that no analysis is made about their potential connections, like synergies or cannibalizations.


### 2.2.6. Risk Monitoring and Control

The main issues of this phase are the way decisions are made (especially in a hierarchy-based management), the rhythm of monitoring and control, and the autonomy that members have in the interval between two risk review meetings.


### 2.2.7. Lessons Learnt

It is generally done at the end of the project, preventing the continual injection of experience all along the project. Second, there may be a huge time interval between the moment things happen and the moment experience is captured, with a possibility of forgetting or being less precise. Third, there may be a risk of blame assigning that may prevent members for journaling what really happened.


## 2.2.1. Definition of Risk Management Principles

This initialization step consists in defining management of Project Risk Management, in which methods, tools, and techniques will be used. However, it generally does not give any idea about the management style, about the level of centralization/decentralization for data gathering, estimation, and authority in decision-making.


## 2.2.2. Risk Identification

It is aimed at listing potential events that could impact, positively or negatively, project activities and objectives. Numerous techniques have been developed in different fields and transposed to Project Risk Management, classified by [23] in analogical [24–27], heuristics-based [28, 29], and analytical methods [30–35]. These methods also theoretically enable opportunities, positive risks, to be included [36, 37]. However, classical methods (even trees or Bayesian networks) are not enough to capture the overall project complexity, for instance, loops. The way actors are organized and behave may also have an impact on risk identification [38].


## 2.2.3. Risk Assessment

It consists in putting qualitative or quantitative estimates to risks, according to several parameters [39–41]. However, it is generally based on only two indicators, probability (or likelihood) and impact (or gravity). Moreover, the assessment of a risk may be different if made by different actors, depending on their role, relation to the risk, and personality.


## 2.2.4. Risk Analysis

It consists in prioritizing risks according to one parameter or a combination of parameters. Classical analysis is often based on combination of probability and impact, either by using a probability-impact diagram or by multiplying both terms to get what is called risk criticality [42]. This involves compensation: two risks, respectively, with (P=1; I = 5) and (P=5; I = 1), will have the same criticality value, albeit they are completely different. Some works have been done to improve this, by reconsidering these diagrams [43–45]. Moreover, when risks are modeled as if they were independent (in a single Excel column for instance), it is impossible to properly assess indirect complexity consequences. Second, it is sometimes a single person who runs the analysis of every risk, either the project manager, the risk manager, or the risk analyst. This involves a clear issue of competence, individual bias, and versatility.


## 2.2.5. Risk Response Planning

It is the process of selecting actions to reduce global risk exposure at minimal cost. The aim is to dispatch available resources, depending on risk criticality and action characteristics (impact and cost) [46]. Different methods exist: zonal-based method, studying actions for different zones of two-axis diagrams [47], WBS-based method [48], linking actions to WBS elements [48], tradeoff method, seeking for one objective while keeping another one under control [49], and optimization-based method [49, 50]. However, the indirect impact or secondary effects of actions are not considered, resulting in undesired impacts like medication. Moreover, actions are generally considered as independent, meaning that no analysis is made about their potential connections, like synergies or cannibalizations.


## 2.2.6. Risk Monitoring and Control

The main issues of this phase are the way decisions are made (especially in a hierarchy-based management), the rhythm of monitoring and control, and the autonomy that members have in the interval between two risk review meetings.


## 2.2.7. Lessons Learnt

It is generally done at the end of the project, preventing the continual injection of experience all along the project. Second, there may be a huge time interval between the moment things happen and the moment experience is captured, with a possibility of forgetting or being less precise. Third, there may be a risk of blame assigning that may prevent members for journaling what really happened.


## 2.3. Research Question

This research work started with two types of industrial relationships. First, we have companies with whom previous research projects had been carried out in order to introduce CST principles in PRM. Conceptual gains were recognized, albeit there were issues about implementation and practical appropriation. Indeed, the way projects were managed, with hierarchy and command-and-control philosophy, prevented this CST-based PRM process to be undertaken with a network of actors. There was a gap between the potential of actors’ coordination and the reality, still centralized. The problem here was thus to introduce alternative management principles into a global, hybrid PRM approach, combining CST and agile principles. Second, companies running their projects with agile principles declared a lack of consideration of PRM. It was because of a lack of reliability of risk management results (analysis and response plans). It is because PRM did not work well that project members used their autonomy to put it at a lower priority level. The problem here is to introduce conceptual improvements into PRM.As shown in Figure1, there are three possible initial situations. In our research work, we ran first introduction of CST-based principles into PRM (arrow 1) and then introduction of APM into the CST-based upgraded PRM process (arrow 2). The second path, which is for us a perspective, is to introduce CST principles into an APM-based organization for managing its risks (arrows 3 and 4). However, for reading convenience and presentation of a generic case, the paper is organized according to arrow 5 of Figure 1, simulating the combined process.Figure 1
Illustration of the diagram of possible paths towards combination of CST and APM into PRM.In order to be as generic as possible, we formulate our research question as follows: how to face complexity, both on its conceptual and managerial aspects, while managing project risks?


## 3. Research Approach

Mäkinen proposes in Table1 a classification of research methodologies [51].Table 1
The 5 groups of research methodologies according to Mäkinen.
TheoreticalEmpiricalDescriptiveConceptual approachNomothetic approachNormativeDecision-oriented approachAction-analysis and constructivist approachesIn this work, we are more in the normative row, since we want to propose prescriptive solutions to be applied within a project. Conceptual issues may be implied on the “theoretical” column; however, the necessity to implement this theory into real life made us choose a constructivist approach. More precisely, Design Science consists in 4 main activities [52]: 1/Build, 2/Evaluate, 3/Conceptualize, and 4/Justify. In our case, a first cycle has been run for introducing CST principles (arrow 1 of Figure 1). The evaluation step allowed us to conceptualize remaining lacks, mostly managerial. This justified the use of CST principles from a conceptual point of view but necessitated building a version 2 in order to improve their implementation into human teams (arrow 2 of Figure 1).


## 4. Running CST-Aided PRM Process Using Agile Principles

In this section, we argue that CST and APM have complementary advantages and limits; this is why we propose combining them into an upgraded PRM process.


### 4.1. Introduction of CST into PRM: Conceptual Advantages and Managerial Limits

Some work has already been done for introducing CST-based principles or methods in PRM, like basic project risk trees (event trees, cause tree, butterfly tree, failure tree), oriented networks without loops (Bayesian project networks), or even project risk networks [53, 54].Previous implementations have shown the interest of such complex system-based techniques applied to Project Risk Management, in terms of prediction precision of risk network potential behavior; however, it has also been observed that limits of this conceptual approach were in the human aspect of implementation [55–57].Some studies and surveys have been done, in order to identify gaps between the theoretical recommendations and the reality of use and practice [58–60]. They notably showed the following: 1/current practices do not correspond to described processes; 2/risk management is not always seen as crucial to projects; 3/people focused more on dangers than on opportunities; 4/project members are more attracted by positive actions (to advance the project) than by defensive risk-related actions; 5/project members may have apprehensions in communicating about problems and risks.This is considered the most important given the emergence of alternative management principles for the last two decades. People increasingly demand changes in the way projects are managed, notably that “managers-leaders provide clear guidance while simultaneously holding team members accountable for their actions” [61]. According to Caron, “it is inevitable that unanticipated events will occur in projects, consequently requiring a time pressured response” [62]. This means a higher level of responsiveness and quick adaptation, meaning that organizations shift towards more autonomy with a distributed governance, like agility [63–65], holacracy [66, 67], sociocracy [68], and liberated companies [69, 70]. The next paragraph will show the complementarity of APM with CST.


### 4.2. Introduction of APM into PRM: Managerial Advantages and Conceptual Limits

Agile Project Management is based on agile values and principles, expressed for the first time in the Agile Manifesto [63], even if methodological components had been initiated and experimented since the mid 80–90 s in software development projects. Agile values are as follows: 1/interactions between people over processes, 2/communication with the client over contract negotiation, 3/delivery over documentation, and 4/adapting to change over respecting a plan. Agile Project Management has emerged in the field of software development projects.Agile management methodologies are based on shorter time horizons for planning and review, more flexibility on planning, and more autonomy given to members. The most known methodology is Scrum, with an emblematic daily meeting, called Scrum meeting (in reference to a rugby team), and an emblematic time period for planning and control, called sprint [71].Agile methodologies have been developed not only to fight some limits of classical command-and-control management, but also to improve adaptability and responsiveness to change [72]. However, there are still many challenges in making decisions, notably about availability and reliability of information when making more frequent, short-term decisions [73].Some papers explored the way risk management can be implemented in agile contexts [74–76], notably the impact of a more distributed management style on risk management [77] or a more precise consideration of uncertainty, distinguishing threats and opportunities [78]. Despite the growth of agile-based methodologies in projects, it has been observed that risk management may remain neglected, sometimes because of the foundations of agility itself. Indeed, giving autonomy to members may involve the fact that they put less effort in an activity that is not seen as crucial or interesting. The other reason is that it is not explicitly suggested in agile methodologies how risks are to be managed [79, 80].Moreover, APM does not propose anything more than classical project management in terms of complexity management. The issue is thus to take complexity under advisement, notably the interdependence between project risks [77, 81], whatever the management style is.Considering this, we claim the usefulness of a conceptual assistance to get complementary information about potential consequences of complexity on project behavior and notably risks. However, and as seen in actual projects, this conceptual assistance is necessary, albeit not sufficient. This is why the managerial aspect should be simultaneously considered, which is the object of the following paragraph.


### 4.3. Integrating Complex Systems Theory (CST) and Agile Project Management (APM) to Face Conceptual and Managerial Issues of Classical Project Risk Management (PRM)

In order to simultaneously address complexity and management issues, a hybrid approach is proposed. The assumption behind this is that APM has consequences in terms of coordination reinforcement, autonomy increase, and improvement of capacity of quickly adapting to chaotic changes, which correspond to requirements of execution of CST-based PRM. CST is a conceptual way to face complexity which is not easy to implement in classical pyramidal management. Agility is a practical way to manage projects which, alone, lacks conceptual assistance for complex PRM. We argue that combination of both will enable improvements to be made, for both project (and its risks) and people.Table2 summarizes the temporal execution of the upgraded PRM process. PRM subprocesses are included in the Agile Project Management cycle (more specifically Scrum methodology). Elements coming from Complex Systems Theory assist some of these PRM subprocesses during several agile meetings.Table 2
Illustration of the correspondence between sequence of processes/steps in PRM, CST, and APM.
Agile Project ManagementProject Risk ManagementComplex Systems TheorySprint planning part 1 (risk network analysis, 2 h)Risk identificationIdentifying risk interdependenciesRisk assessmentAssessing risk interdependenciesRisk analysisAnalyzing risk interdependencies and their potential consequencesSprint planning part 2 (risk response plan, 2 h)Risk response actions identificationIdentifying action interdependenciesRisk response actions assessmentAssessing action interdependenciesRisk response actions analysisAnalyzing action interdependencies and their potential consequencesRisk response plan decisionMaking decisions under complex contextsRisk-oriented reorganizationInterdependency-based clusteringScrum meeting (15 minutes)Risk monitoring and controlQuick update of interdependencies, analyses, and decisionsSprint review (1 h)Risk monitoring and controlSprint retrospective (less than 1 h)Lessons learntRisk management principles (update)An example will be introduced all along the paper to progressively illustrate the approach, based on a former tramway system design and construction project. It consisted of delivery of the infrastructure, Civil Work (including stations and maintenance depots), equipment (like traffic signaling, operating control, and command center), and rolling stocks for the future tramway of a 750,000-inhabitant city. Information related to this example will be in italics.


## 4.1. Introduction of CST into PRM: Conceptual Advantages and Managerial Limits

Some work has already been done for introducing CST-based principles or methods in PRM, like basic project risk trees (event trees, cause tree, butterfly tree, failure tree), oriented networks without loops (Bayesian project networks), or even project risk networks [53, 54].Previous implementations have shown the interest of such complex system-based techniques applied to Project Risk Management, in terms of prediction precision of risk network potential behavior; however, it has also been observed that limits of this conceptual approach were in the human aspect of implementation [55–57].Some studies and surveys have been done, in order to identify gaps between the theoretical recommendations and the reality of use and practice [58–60]. They notably showed the following: 1/current practices do not correspond to described processes; 2/risk management is not always seen as crucial to projects; 3/people focused more on dangers than on opportunities; 4/project members are more attracted by positive actions (to advance the project) than by defensive risk-related actions; 5/project members may have apprehensions in communicating about problems and risks.This is considered the most important given the emergence of alternative management principles for the last two decades. People increasingly demand changes in the way projects are managed, notably that “managers-leaders provide clear guidance while simultaneously holding team members accountable for their actions” [61]. According to Caron, “it is inevitable that unanticipated events will occur in projects, consequently requiring a time pressured response” [62]. This means a higher level of responsiveness and quick adaptation, meaning that organizations shift towards more autonomy with a distributed governance, like agility [63–65], holacracy [66, 67], sociocracy [68], and liberated companies [69, 70]. The next paragraph will show the complementarity of APM with CST.


## 4.2. Introduction of APM into PRM: Managerial Advantages and Conceptual Limits

Agile Project Management is based on agile values and principles, expressed for the first time in the Agile Manifesto [63], even if methodological components had been initiated and experimented since the mid 80–90 s in software development projects. Agile values are as follows: 1/interactions between people over processes, 2/communication with the client over contract negotiation, 3/delivery over documentation, and 4/adapting to change over respecting a plan. Agile Project Management has emerged in the field of software development projects.Agile management methodologies are based on shorter time horizons for planning and review, more flexibility on planning, and more autonomy given to members. The most known methodology is Scrum, with an emblematic daily meeting, called Scrum meeting (in reference to a rugby team), and an emblematic time period for planning and control, called sprint [71].Agile methodologies have been developed not only to fight some limits of classical command-and-control management, but also to improve adaptability and responsiveness to change [72]. However, there are still many challenges in making decisions, notably about availability and reliability of information when making more frequent, short-term decisions [73].Some papers explored the way risk management can be implemented in agile contexts [74–76], notably the impact of a more distributed management style on risk management [77] or a more precise consideration of uncertainty, distinguishing threats and opportunities [78]. Despite the growth of agile-based methodologies in projects, it has been observed that risk management may remain neglected, sometimes because of the foundations of agility itself. Indeed, giving autonomy to members may involve the fact that they put less effort in an activity that is not seen as crucial or interesting. The other reason is that it is not explicitly suggested in agile methodologies how risks are to be managed [79, 80].Moreover, APM does not propose anything more than classical project management in terms of complexity management. The issue is thus to take complexity under advisement, notably the interdependence between project risks [77, 81], whatever the management style is.Considering this, we claim the usefulness of a conceptual assistance to get complementary information about potential consequences of complexity on project behavior and notably risks. However, and as seen in actual projects, this conceptual assistance is necessary, albeit not sufficient. This is why the managerial aspect should be simultaneously considered, which is the object of the following paragraph.


## 4.3. Integrating Complex Systems Theory (CST) and Agile Project Management (APM) to Face Conceptual and Managerial Issues of Classical Project Risk Management (PRM)

In order to simultaneously address complexity and management issues, a hybrid approach is proposed. The assumption behind this is that APM has consequences in terms of coordination reinforcement, autonomy increase, and improvement of capacity of quickly adapting to chaotic changes, which correspond to requirements of execution of CST-based PRM. CST is a conceptual way to face complexity which is not easy to implement in classical pyramidal management. Agility is a practical way to manage projects which, alone, lacks conceptual assistance for complex PRM. We argue that combination of both will enable improvements to be made, for both project (and its risks) and people.Table2 summarizes the temporal execution of the upgraded PRM process. PRM subprocesses are included in the Agile Project Management cycle (more specifically Scrum methodology). Elements coming from Complex Systems Theory assist some of these PRM subprocesses during several agile meetings.Table 2
Illustration of the correspondence between sequence of processes/steps in PRM, CST, and APM.
Agile Project ManagementProject Risk ManagementComplex Systems TheorySprint planning part 1 (risk network analysis, 2 h)Risk identificationIdentifying risk interdependenciesRisk assessmentAssessing risk interdependenciesRisk analysisAnalyzing risk interdependencies and their potential consequencesSprint planning part 2 (risk response plan, 2 h)Risk response actions identificationIdentifying action interdependenciesRisk response actions assessmentAssessing action interdependenciesRisk response actions analysisAnalyzing action interdependencies and their potential consequencesRisk response plan decisionMaking decisions under complex contextsRisk-oriented reorganizationInterdependency-based clusteringScrum meeting (15 minutes)Risk monitoring and controlQuick update of interdependencies, analyses, and decisionsSprint review (1 h)Risk monitoring and controlSprint retrospective (less than 1 h)Lessons learntRisk management principles (update)An example will be introduced all along the paper to progressively illustrate the approach, based on a former tramway system design and construction project. It consisted of delivery of the infrastructure, Civil Work (including stations and maintenance depots), equipment (like traffic signaling, operating control, and command center), and rolling stocks for the future tramway of a 750,000-inhabitant city. Information related to this example will be in italics.


## 5. Sprint Planning Part 1: Agile Risk Network Analysis

A sprint is a repeated work cycle usually lasting from one to four weeks. Sprint planning is aimed at prioritizing sprint backlog, what is expected to be done during this sprint. This section introduces the adaptation of sprint planning to the context of CST-aided PRM, by a first 3-step meeting: risk network identification, assessment, and analysis. Next section will introduce the second part of the risk sprint planning, with a second meeting dedicated to make decisions about risk response actions. The first time in which these meetings are run is expected to be longer, so they are separated. After several sprints, their duration diminishes, and they are susceptible to be run as a single half-day meeting (2 h typically).


### 5.1. Risk Network Identification

Risk interdependencies identification is done as a complement to risk identification.


#### 5.1.1. Identifying Risks

Risk identification is aimed at listing potential events that could impact, positively or negatively, project activities and objectives. In some cases, the word opportunity is used for positive risks.For the tramway project example, risks were identified and managed by the project director and his project management team. At the time where the CST-oriented study started, there were 42 risks in the list, owned by 11 different actors.


#### 5.1.2. Identifying Interdependencies between Risks

Several terms exist such as interdependence, interaction, interrelation, relationship, and even interface. They are sometimes used for modeling similar concepts, albeit with slight differences. We keep the notion of interdependence, which exists “when actions in one subunit of the organization affect important outcomes in another subunit” [82]. Many types of interdependence have been modeled, like sequence, coupling, conditional interdependence, cause and effect, resource sharing, objective sharing, and contribution [82–84].Those who may correspond to our context of Project Risk Management refer to the interdependence between risks and between risk response actions. Modeling interdependence between project risks relies on two things: how to get this information and how to represent and manage it. Obtaining interdependence-related information is based on three techniques: 1/direct identification from project risk lists obtained with specific techniques like trees, FMECA, or Bayesian networks; 2/direct identification from creativity-based or systematic analysis of risk lists; and 3/indirect identification, stemming from existing interdependencies in other project documents, related to the product, the process, or the organization. Indirect identification has been studied in [85], by analyzing the correspondence between risks and project elements, as dual spaces in mathematics, in order to draw information about one space from information about the other space. If two project elements are interdependent, there is a possibility of interdependence between the attendant risks.The notion of interdependence between two risks is thus defined as the possibility of impact of an initial event triggering the occurrence of a final event. In this step, only the existence of a potential interdependence between two risks is studied. Then, this information is modeled using matrix-based and graph-based techniques, in order to get a 2D binary model of the project risk network [3].


#### 5.1.3. Agile Risk Network Identification

The use of APM-based principles naturally involves running this identification step as a team and not individually. The identified risks can be put into a Kanban tool. In APM, a Kanban is a multilist tool for managing tasks, moving tasks within a list (like a waiting queue), and between lists (if tasks status changes). This allows for prioritizing tasks and keeping list size reasonable. In our context, each risk appears as the so-called card in a list of the Kanban. This list is called “Needs assessment and analysis,” meaning that risks are identified, but their parameters are not known yet.Interdependencies between risks can also be directly modeled in the Kanban tool. As a risk,Ri declares an interdependency with another risk Rj; then, this tool automatically duplicates the information into Rj card. Then, there is on each card a clickable link to navigate from the origin risk to the risk it is related. People have to coordinate to validate the reciprocity of interdependency (does the owner of risk Rj agree that this risk is related to risk Ri, as declared by owner of Ri?).For the tramway project, the project management team mostly used a systematic review of each risk, for identifying potential causes and effects. 14 risks were added to the initial 42-risk list. This additional inclusion of 14 risks (one-third or more) occurs specifically due to this additional CST-based activity. When identifying interdependencies for each risk, many causes and effects were already modeled, but some were not (or they were in lower-level lists). Three additional risks were notably added because they serve as intermediary events between risks already existing in the list. 95 interdependencies have been identified, 41 of them between the 42 initial risks. This means that there are 54 additional interdependencies involved (more than twice the initial number). As illustrated in Figure2, we moved from an initial list of 42 risks, managed as if they were independent, to a matrix where interdependencies between 56 risks are now identified.Figure 2
From an initial 42-risk list to a 56∗ 56 risk interdependence matrix (tramway project case).


### 5.2. Risk Network Assessment

The second part of the process consists of assessing first risks and then their interdependencies.


#### 5.2.1. Classical Risk Assessment

Basic PRM principles for risk assessment are the use of qualitative or quantitative methods, depending on the context, the data availability, the client’s requirement, and the available time. Classical parameters are probability (or likelihood) and impact (or gravity).In the tramway project, existing scales were 10-level discrete scales, for probability and impact. Knowing that 12 additional risks had been considered, the complete 56-risk list with initial qualitative assessment is given in Table3.Table 3
The 56-risk list with associated class, owner, and assessment.
IDRisk nameClassOwnerProbabilityGravityCriticality1Safety studiesTechnical11112Liquidated damages on intermediate milestone and delay of Progress Payment ThresholdContractual278563Vehicle storage in another cityContractual195454Vandalism on-siteContractual31335Traction/braking function: behavior in degraded mode on slopeTechnical13266New local laws and regulationsContractual11337Traffic signaling, priority at intersectionsContractual465308Unclear interface with the client, for infrastructure equipmentContractual51229Delays due to client late decisionsContractual591910Travel time performanceTechnical413311Limited force majeure definitionContractual214412Operating certificate delayContractual2943613Reliability and availability targetsTechnical433914Permissions and authorizationsContractual2921815Insurance deductiblesFinancial613316Archeological findingsContractual2932717Discrepancies client/operator/concessionaireContractual7351518Civil Work delay and continuityContractual8943619Responsibility of client on Civil Work delayContractual2921820On board CCTV scopeTechnical951521Noise and vibration attenuationTechnical4361822Potential risks of claim from Civil Work subcontractorContractual2552523Harmonics levelTechnical512224Noncompliance contractual rolling stockTechnical116625Noncompliance technical specifications Rolling stockContractual1341226Exchange risk on suppliersFinancial613327Track installation machine performanceClient/partner/subcontractor1032628Tax risk on onshoreFinancial612229Additional poles over cost for tramway companyContractual5943630Over cost due to security requirements for trainsTechnical4542031Track insulationTechnical911132Delay for energizingProject management, construction site532633Fare collection requirementsContractual7531534Construction safety interfacesTechnical311135Electromagnetic interferencesTechnical412236Exchange riskFinancial612237Risk of partial rejection of our request for EOT (Extension of Time)Contractual2976338Interface rail/wheelTechnical432639Risk on certification of our equipmentCountry1112240OCS installationProject management, construction site3753541Banks stopping financing the projectContractual2732142Costs of modifications not covered by EOT agreementContractual214443Return profit decreaseFinancial2987244Extra trainsContractual416645Pedestrian zonesTechnical412246Train performanceTechnical132647Waiting time at stationsContractual451548Depot delayTechnical3921849Error in the survey (topography)Technical411150Ticketing design delaysContractual771751Track installation delayTechnical3721452Reengineering/redesignTechnical4921853Slabs pouring delayTechnical351554Initial specifications of CW (Civil Work)Technical351555Available cash flow decreaseFinancial2976356Rolling stock delivery delayTechnical1313Classically, this step finishes here and is directly followed by analysis. Here, a complementary CST-based assessment is made, in order to assess risk interdependencies.


#### 5.2.2. Risk Interdependency Assessment

The fact that a possible interdependency has been identified fromRi to Rj means that when Ri occurs, there is a chance of Rj occurring as well as a consequence of Ri. This is called P(Rj∣Ri), the probability of Rj knowing Ri, also called conditional probability.The agile principle used here is the decentralized, distributed assessment. Each project member is supposed to be mature enough to self-assess her risks. Of course, a collective refinement may be conducted to detect and correct possible bias, but agile management generally relies on trust and autonomy. It involves an assistance to autonomous decisions rather than control or centralized decisions.Two approaches may be used. The first one is to directly evaluate interdependencies using expert judgment. The second one is to use relative comparisons, for instance, the pairwise comparison Analytic Hierarchy Process [81, 86–88].


#### 5.2.3. Agile Risk Network Assessment

In the tramway project, local pairwise comparison has been used; i.e., each Risk Owner has analyzed her direct interdependencies. This is a distributed, agile-like version where the assessment is done by the person who is at first concerned. It uses the following process: 1/decomposing the problem into two subproblems for each node of the interdependence (Ri and Rj); 2/comparing the relative strength of interdependencies, for each node with Ri as origin, and each node with Rj as end; 3/extracting eigenvectors of the corresponding adjacency matrix; 4/aggregating results for Ri and for Rj; 5/compiling results for the Ri − Rj interdependency (averaging perception of interdependence with Rj by Ri and perception of interdependence with Ri by Rj). The same persons as for interdependence identification were solicited for step 2 (comparing relative strength of interdependent nodes).Using the binary network and a 10-level scale, assessment has been done for the 95 interdependencies (Figure3). 12 of them had a strong value (9 or 10), 19 had an average value (from 6 to 8), and 64 had a low value.Figure 3
Illustration of the assessment of the 95 interdependencies between the 56 risks of the tramway project.


### 5.3. Risk Network Analysis

As previously discussed, the originality of this work is to add information about risks interdependencies in order to make a better-informed analysis.


#### 5.3.1. Classical Individual Risk Analysis

Basic risk analysis consists in prioritizing risks according to their individual criticality, generally defined as the product of probability and impact. The higher the criticality is, the more important the risk is. This is what we callIndividual Importance of the risk, i.e., the impact that the risk may have and if it occurs, all things become equal.In the tramway project, only several risks were really critical (top-right quarter of the Farmer diagram of Figure4). A lot of them have a high likelihood but weak impact (top-left quarter of the diagram). Very few risks have a high impact and low probability (down-right quarter of Figure 4). This is in this diagonal that tradeoffs have to be made, and, for the moment, decision-makers do not face complicated situations. However, they do not have any idea with this diagram about the role, the contribution of the risks within the network.Figure 4
Initial Farmer diagram of the tramway project.


#### 5.3.2. Advanced Network Analysis

Several types of advanced techniques can be used. We distinguish here topological analysis, based on the static analysis of a snapshot of the network [89–91], based on topological indicators, like centrality, eigenvalues, betweenness [57], and propagation analysis, based on the dynamic simulation of potential behavior of the network [56, 92–95]. Both can help to estimate what we call Collective Importance of the risk, which is the contribution of the risk to the global behavior of the network. It depends on the position of the risk in the network and on the nature of the network.For instance, a risk with multiple direct and indirect effects will be considered as more important than an isolated risk (with no consequence except its direct impact), at an equal level of Individual Importance, since it may trigger the occurrence of impacts related to other risks in a propagation chain.In the tramway project example (Figure5), risks in red have a stronger contribution to the network behavior than other risks, independent of their individual value. Red triangles at the top of the figure (risks R49, R27, R16, and R19) are sources, meaning that they do not necessarily have a high individual criticality (between 1 and 36, 81 being the maximal value), albeit they have strong indirect consequences. Red diamonds (risks R10, R13, R39, and R12) have multiple indirect causes and multiple indirect effects. They act as hubs in the network. This is particularly dangerous when it propagates a failure from one part of the project (i.e., train design) to another part of the project (Civil Work construction), which is the case of R12. Finally, red triangles at the bottom of the figure (R2, R43, R52, and R55) are accumulation risks, meaning that they have numerous causes. An interesting point here is that three of them were not in the initial list (without complementary CST-based activity), albeit their title gives an idea about their importance (respectively, “return profit decrease,” “reengineering/redesign,” and “available cash flow decrease,”). A feedback from managers was that of course these risks were implicitly considered; however they did not know about the quantity and the complex nature of relationships between these risks and the rest of the project.Figure 5
Illustration of a network theory-based analysis of project risk interdependence.


#### 5.3.3. Agile Risk Network Analysis

On the opposite of classical management styles, there is a role that coordinates this phase, called Risk Owner, albeit he/she does not have the authority for assigning members to actions. They decide, with discussion and sometimes votes, what items are included in the risk sprint backlog, under the supervision of the Risk Owner (which is a transposition to risks of the classical Product Owner role).To assist this collective prioritization step, a new type of risk diagram is proposed. It still combines Individual Importance (the individual criticality) and Collective Importance (Figure6). This means that, in this new complementary diagram, a risk will be considered as critical if and only if it is individually critical and collectively critical. This is an originality compared to classical Farmer diagram, where a risk is considered as critical if it is individually critical.Figure 6
Illustration of an original Farmer-like diagram combining Individual and Collective Importance of risks.Tramway project is illustrated in Figure6. Just as in classical Farmer diagrams, or heat map matrices, a grid is defined in order to distinguish priority levels. This is generally done using different colors. Let us call Individual Importance II and Collective Importance CI. In Figure 6, we can see that the cell with II = 1 and CI = 5 is red and the one with II = 5 and CI = 1 is yellow. So, R10 “travel time performance” will have a red priority, albeit, in classical analysis based on individual criticality only, it would have been considered as negligible (II = 1). On the opposite, risk R3 “vehicle storage in another city” has a strong individual criticality and would have been in the top priority in classical risk analysis. In our case, this is balanced with contribution to the rest of the network. Since R3 is in a yellow cell, R10, albeit less critical individually speaking, will have a higher priority at the end of the CST-based analysis.Finally, following APM-based principles, a risk backlog is created in the Kanban, entitled “Needs decision.” The risk backlog is treated as a queue, with resources being assigned to response actions depending on the place of the risk in this queue.In order to help prioritizing risks, a popular and collective tool in agility is the vote, either binary or weighted, for instance, using the Fibonacci series. Voting is not necessary for all risks, albeit beneficial for three difficult situations: 1/in case of indifference, or proximity of two risks, for instance, in the same cell of Figure6 matrix, or in neighbor cells, since we know that assessment lacks precision; 2/in case of incomparability, when two risks have the same color but are completely different, like R22 “potential risks of claim from Civil Work subcontractor” and R3 “vehicle storage in another city” in Figure 6; 3/in case of differences of perception between actors, because a risk does not have the same impact on every actor. Indeed, actors vote according to their own perception, depending on their own vulnerability to each specific risk. The concept of ordered waiting queue is important in agility, since it gives an idea of priorities. The next section introduces the phase of risk response planning, with contributions coming from CST and APM.


## 5.1. Risk Network Identification

Risk interdependencies identification is done as a complement to risk identification.


### 5.1.1. Identifying Risks

Risk identification is aimed at listing potential events that could impact, positively or negatively, project activities and objectives. In some cases, the word opportunity is used for positive risks.For the tramway project example, risks were identified and managed by the project director and his project management team. At the time where the CST-oriented study started, there were 42 risks in the list, owned by 11 different actors.


### 5.1.2. Identifying Interdependencies between Risks

Several terms exist such as interdependence, interaction, interrelation, relationship, and even interface. They are sometimes used for modeling similar concepts, albeit with slight differences. We keep the notion of interdependence, which exists “when actions in one subunit of the organization affect important outcomes in another subunit” [82]. Many types of interdependence have been modeled, like sequence, coupling, conditional interdependence, cause and effect, resource sharing, objective sharing, and contribution [82–84].Those who may correspond to our context of Project Risk Management refer to the interdependence between risks and between risk response actions. Modeling interdependence between project risks relies on two things: how to get this information and how to represent and manage it. Obtaining interdependence-related information is based on three techniques: 1/direct identification from project risk lists obtained with specific techniques like trees, FMECA, or Bayesian networks; 2/direct identification from creativity-based or systematic analysis of risk lists; and 3/indirect identification, stemming from existing interdependencies in other project documents, related to the product, the process, or the organization. Indirect identification has been studied in [85], by analyzing the correspondence between risks and project elements, as dual spaces in mathematics, in order to draw information about one space from information about the other space. If two project elements are interdependent, there is a possibility of interdependence between the attendant risks.The notion of interdependence between two risks is thus defined as the possibility of impact of an initial event triggering the occurrence of a final event. In this step, only the existence of a potential interdependence between two risks is studied. Then, this information is modeled using matrix-based and graph-based techniques, in order to get a 2D binary model of the project risk network [3].


### 5.1.3. Agile Risk Network Identification

The use of APM-based principles naturally involves running this identification step as a team and not individually. The identified risks can be put into a Kanban tool. In APM, a Kanban is a multilist tool for managing tasks, moving tasks within a list (like a waiting queue), and between lists (if tasks status changes). This allows for prioritizing tasks and keeping list size reasonable. In our context, each risk appears as the so-called card in a list of the Kanban. This list is called “Needs assessment and analysis,” meaning that risks are identified, but their parameters are not known yet.Interdependencies between risks can also be directly modeled in the Kanban tool. As a risk,Ri declares an interdependency with another risk Rj; then, this tool automatically duplicates the information into Rj card. Then, there is on each card a clickable link to navigate from the origin risk to the risk it is related. People have to coordinate to validate the reciprocity of interdependency (does the owner of risk Rj agree that this risk is related to risk Ri, as declared by owner of Ri?).For the tramway project, the project management team mostly used a systematic review of each risk, for identifying potential causes and effects. 14 risks were added to the initial 42-risk list. This additional inclusion of 14 risks (one-third or more) occurs specifically due to this additional CST-based activity. When identifying interdependencies for each risk, many causes and effects were already modeled, but some were not (or they were in lower-level lists). Three additional risks were notably added because they serve as intermediary events between risks already existing in the list. 95 interdependencies have been identified, 41 of them between the 42 initial risks. This means that there are 54 additional interdependencies involved (more than twice the initial number). As illustrated in Figure2, we moved from an initial list of 42 risks, managed as if they were independent, to a matrix where interdependencies between 56 risks are now identified.Figure 2
From an initial 42-risk list to a 56∗ 56 risk interdependence matrix (tramway project case).


## 5.1.1. Identifying Risks

Risk identification is aimed at listing potential events that could impact, positively or negatively, project activities and objectives. In some cases, the word opportunity is used for positive risks.For the tramway project example, risks were identified and managed by the project director and his project management team. At the time where the CST-oriented study started, there were 42 risks in the list, owned by 11 different actors.


## 5.1.2. Identifying Interdependencies between Risks

Several terms exist such as interdependence, interaction, interrelation, relationship, and even interface. They are sometimes used for modeling similar concepts, albeit with slight differences. We keep the notion of interdependence, which exists “when actions in one subunit of the organization affect important outcomes in another subunit” [82]. Many types of interdependence have been modeled, like sequence, coupling, conditional interdependence, cause and effect, resource sharing, objective sharing, and contribution [82–84].Those who may correspond to our context of Project Risk Management refer to the interdependence between risks and between risk response actions. Modeling interdependence between project risks relies on two things: how to get this information and how to represent and manage it. Obtaining interdependence-related information is based on three techniques: 1/direct identification from project risk lists obtained with specific techniques like trees, FMECA, or Bayesian networks; 2/direct identification from creativity-based or systematic analysis of risk lists; and 3/indirect identification, stemming from existing interdependencies in other project documents, related to the product, the process, or the organization. Indirect identification has been studied in [85], by analyzing the correspondence between risks and project elements, as dual spaces in mathematics, in order to draw information about one space from information about the other space. If two project elements are interdependent, there is a possibility of interdependence between the attendant risks.The notion of interdependence between two risks is thus defined as the possibility of impact of an initial event triggering the occurrence of a final event. In this step, only the existence of a potential interdependence between two risks is studied. Then, this information is modeled using matrix-based and graph-based techniques, in order to get a 2D binary model of the project risk network [3].


## 5.1.3. Agile Risk Network Identification

The use of APM-based principles naturally involves running this identification step as a team and not individually. The identified risks can be put into a Kanban tool. In APM, a Kanban is a multilist tool for managing tasks, moving tasks within a list (like a waiting queue), and between lists (if tasks status changes). This allows for prioritizing tasks and keeping list size reasonable. In our context, each risk appears as the so-called card in a list of the Kanban. This list is called “Needs assessment and analysis,” meaning that risks are identified, but their parameters are not known yet.Interdependencies between risks can also be directly modeled in the Kanban tool. As a risk,Ri declares an interdependency with another risk Rj; then, this tool automatically duplicates the information into Rj card. Then, there is on each card a clickable link to navigate from the origin risk to the risk it is related. People have to coordinate to validate the reciprocity of interdependency (does the owner of risk Rj agree that this risk is related to risk Ri, as declared by owner of Ri?).For the tramway project, the project management team mostly used a systematic review of each risk, for identifying potential causes and effects. 14 risks were added to the initial 42-risk list. This additional inclusion of 14 risks (one-third or more) occurs specifically due to this additional CST-based activity. When identifying interdependencies for each risk, many causes and effects were already modeled, but some were not (or they were in lower-level lists). Three additional risks were notably added because they serve as intermediary events between risks already existing in the list. 95 interdependencies have been identified, 41 of them between the 42 initial risks. This means that there are 54 additional interdependencies involved (more than twice the initial number). As illustrated in Figure2, we moved from an initial list of 42 risks, managed as if they were independent, to a matrix where interdependencies between 56 risks are now identified.Figure 2
From an initial 42-risk list to a 56∗ 56 risk interdependence matrix (tramway project case).


## 5.2. Risk Network Assessment

The second part of the process consists of assessing first risks and then their interdependencies.


### 5.2.1. Classical Risk Assessment

Basic PRM principles for risk assessment are the use of qualitative or quantitative methods, depending on the context, the data availability, the client’s requirement, and the available time. Classical parameters are probability (or likelihood) and impact (or gravity).In the tramway project, existing scales were 10-level discrete scales, for probability and impact. Knowing that 12 additional risks had been considered, the complete 56-risk list with initial qualitative assessment is given in Table3.Table 3
The 56-risk list with associated class, owner, and assessment.
IDRisk nameClassOwnerProbabilityGravityCriticality1Safety studiesTechnical11112Liquidated damages on intermediate milestone and delay of Progress Payment ThresholdContractual278563Vehicle storage in another cityContractual195454Vandalism on-siteContractual31335Traction/braking function: behavior in degraded mode on slopeTechnical13266New local laws and regulationsContractual11337Traffic signaling, priority at intersectionsContractual465308Unclear interface with the client, for infrastructure equipmentContractual51229Delays due to client late decisionsContractual591910Travel time performanceTechnical413311Limited force majeure definitionContractual214412Operating certificate delayContractual2943613Reliability and availability targetsTechnical433914Permissions and authorizationsContractual2921815Insurance deductiblesFinancial613316Archeological findingsContractual2932717Discrepancies client/operator/concessionaireContractual7351518Civil Work delay and continuityContractual8943619Responsibility of client on Civil Work delayContractual2921820On board CCTV scopeTechnical951521Noise and vibration attenuationTechnical4361822Potential risks of claim from Civil Work subcontractorContractual2552523Harmonics levelTechnical512224Noncompliance contractual rolling stockTechnical116625Noncompliance technical specifications Rolling stockContractual1341226Exchange risk on suppliersFinancial613327Track installation machine performanceClient/partner/subcontractor1032628Tax risk on onshoreFinancial612229Additional poles over cost for tramway companyContractual5943630Over cost due to security requirements for trainsTechnical4542031Track insulationTechnical911132Delay for energizingProject management, construction site532633Fare collection requirementsContractual7531534Construction safety interfacesTechnical311135Electromagnetic interferencesTechnical412236Exchange riskFinancial612237Risk of partial rejection of our request for EOT (Extension of Time)Contractual2976338Interface rail/wheelTechnical432639Risk on certification of our equipmentCountry1112240OCS installationProject management, construction site3753541Banks stopping financing the projectContractual2732142Costs of modifications not covered by EOT agreementContractual214443Return profit decreaseFinancial2987244Extra trainsContractual416645Pedestrian zonesTechnical412246Train performanceTechnical132647Waiting time at stationsContractual451548Depot delayTechnical3921849Error in the survey (topography)Technical411150Ticketing design delaysContractual771751Track installation delayTechnical3721452Reengineering/redesignTechnical4921853Slabs pouring delayTechnical351554Initial specifications of CW (Civil Work)Technical351555Available cash flow decreaseFinancial2976356Rolling stock delivery delayTechnical1313Classically, this step finishes here and is directly followed by analysis. Here, a complementary CST-based assessment is made, in order to assess risk interdependencies.


### 5.2.2. Risk Interdependency Assessment

The fact that a possible interdependency has been identified fromRi to Rj means that when Ri occurs, there is a chance of Rj occurring as well as a consequence of Ri. This is called P(Rj∣Ri), the probability of Rj knowing Ri, also called conditional probability.The agile principle used here is the decentralized, distributed assessment. Each project member is supposed to be mature enough to self-assess her risks. Of course, a collective refinement may be conducted to detect and correct possible bias, but agile management generally relies on trust and autonomy. It involves an assistance to autonomous decisions rather than control or centralized decisions.Two approaches may be used. The first one is to directly evaluate interdependencies using expert judgment. The second one is to use relative comparisons, for instance, the pairwise comparison Analytic Hierarchy Process [81, 86–88].


### 5.2.3. Agile Risk Network Assessment

In the tramway project, local pairwise comparison has been used; i.e., each Risk Owner has analyzed her direct interdependencies. This is a distributed, agile-like version where the assessment is done by the person who is at first concerned. It uses the following process: 1/decomposing the problem into two subproblems for each node of the interdependence (Ri and Rj); 2/comparing the relative strength of interdependencies, for each node with Ri as origin, and each node with Rj as end; 3/extracting eigenvectors of the corresponding adjacency matrix; 4/aggregating results for Ri and for Rj; 5/compiling results for the Ri − Rj interdependency (averaging perception of interdependence with Rj by Ri and perception of interdependence with Ri by Rj). The same persons as for interdependence identification were solicited for step 2 (comparing relative strength of interdependent nodes).Using the binary network and a 10-level scale, assessment has been done for the 95 interdependencies (Figure3). 12 of them had a strong value (9 or 10), 19 had an average value (from 6 to 8), and 64 had a low value.Figure 3
Illustration of the assessment of the 95 interdependencies between the 56 risks of the tramway project.


## 5.2.1. Classical Risk Assessment

Basic PRM principles for risk assessment are the use of qualitative or quantitative methods, depending on the context, the data availability, the client’s requirement, and the available time. Classical parameters are probability (or likelihood) and impact (or gravity).In the tramway project, existing scales were 10-level discrete scales, for probability and impact. Knowing that 12 additional risks had been considered, the complete 56-risk list with initial qualitative assessment is given in Table3.Table 3
The 56-risk list with associated class, owner, and assessment.
IDRisk nameClassOwnerProbabilityGravityCriticality1Safety studiesTechnical11112Liquidated damages on intermediate milestone and delay of Progress Payment ThresholdContractual278563Vehicle storage in another cityContractual195454Vandalism on-siteContractual31335Traction/braking function: behavior in degraded mode on slopeTechnical13266New local laws and regulationsContractual11337Traffic signaling, priority at intersectionsContractual465308Unclear interface with the client, for infrastructure equipmentContractual51229Delays due to client late decisionsContractual591910Travel time performanceTechnical413311Limited force majeure definitionContractual214412Operating certificate delayContractual2943613Reliability and availability targetsTechnical433914Permissions and authorizationsContractual2921815Insurance deductiblesFinancial613316Archeological findingsContractual2932717Discrepancies client/operator/concessionaireContractual7351518Civil Work delay and continuityContractual8943619Responsibility of client on Civil Work delayContractual2921820On board CCTV scopeTechnical951521Noise and vibration attenuationTechnical4361822Potential risks of claim from Civil Work subcontractorContractual2552523Harmonics levelTechnical512224Noncompliance contractual rolling stockTechnical116625Noncompliance technical specifications Rolling stockContractual1341226Exchange risk on suppliersFinancial613327Track installation machine performanceClient/partner/subcontractor1032628Tax risk on onshoreFinancial612229Additional poles over cost for tramway companyContractual5943630Over cost due to security requirements for trainsTechnical4542031Track insulationTechnical911132Delay for energizingProject management, construction site532633Fare collection requirementsContractual7531534Construction safety interfacesTechnical311135Electromagnetic interferencesTechnical412236Exchange riskFinancial612237Risk of partial rejection of our request for EOT (Extension of Time)Contractual2976338Interface rail/wheelTechnical432639Risk on certification of our equipmentCountry1112240OCS installationProject management, construction site3753541Banks stopping financing the projectContractual2732142Costs of modifications not covered by EOT agreementContractual214443Return profit decreaseFinancial2987244Extra trainsContractual416645Pedestrian zonesTechnical412246Train performanceTechnical132647Waiting time at stationsContractual451548Depot delayTechnical3921849Error in the survey (topography)Technical411150Ticketing design delaysContractual771751Track installation delayTechnical3721452Reengineering/redesignTechnical4921853Slabs pouring delayTechnical351554Initial specifications of CW (Civil Work)Technical351555Available cash flow decreaseFinancial2976356Rolling stock delivery delayTechnical1313Classically, this step finishes here and is directly followed by analysis. Here, a complementary CST-based assessment is made, in order to assess risk interdependencies.


## 5.2.2. Risk Interdependency Assessment

The fact that a possible interdependency has been identified fromRi to Rj means that when Ri occurs, there is a chance of Rj occurring as well as a consequence of Ri. This is called P(Rj∣Ri), the probability of Rj knowing Ri, also called conditional probability.The agile principle used here is the decentralized, distributed assessment. Each project member is supposed to be mature enough to self-assess her risks. Of course, a collective refinement may be conducted to detect and correct possible bias, but agile management generally relies on trust and autonomy. It involves an assistance to autonomous decisions rather than control or centralized decisions.Two approaches may be used. The first one is to directly evaluate interdependencies using expert judgment. The second one is to use relative comparisons, for instance, the pairwise comparison Analytic Hierarchy Process [81, 86–88].


## 5.2.3. Agile Risk Network Assessment

In the tramway project, local pairwise comparison has been used; i.e., each Risk Owner has analyzed her direct interdependencies. This is a distributed, agile-like version where the assessment is done by the person who is at first concerned. It uses the following process: 1/decomposing the problem into two subproblems for each node of the interdependence (Ri and Rj); 2/comparing the relative strength of interdependencies, for each node with Ri as origin, and each node with Rj as end; 3/extracting eigenvectors of the corresponding adjacency matrix; 4/aggregating results for Ri and for Rj; 5/compiling results for the Ri − Rj interdependency (averaging perception of interdependence with Rj by Ri and perception of interdependence with Ri by Rj). The same persons as for interdependence identification were solicited for step 2 (comparing relative strength of interdependent nodes).Using the binary network and a 10-level scale, assessment has been done for the 95 interdependencies (Figure3). 12 of them had a strong value (9 or 10), 19 had an average value (from 6 to 8), and 64 had a low value.Figure 3
Illustration of the assessment of the 95 interdependencies between the 56 risks of the tramway project.


## 5.3. Risk Network Analysis

As previously discussed, the originality of this work is to add information about risks interdependencies in order to make a better-informed analysis.


### 5.3.1. Classical Individual Risk Analysis

Basic risk analysis consists in prioritizing risks according to their individual criticality, generally defined as the product of probability and impact. The higher the criticality is, the more important the risk is. This is what we callIndividual Importance of the risk, i.e., the impact that the risk may have and if it occurs, all things become equal.In the tramway project, only several risks were really critical (top-right quarter of the Farmer diagram of Figure4). A lot of them have a high likelihood but weak impact (top-left quarter of the diagram). Very few risks have a high impact and low probability (down-right quarter of Figure 4). This is in this diagonal that tradeoffs have to be made, and, for the moment, decision-makers do not face complicated situations. However, they do not have any idea with this diagram about the role, the contribution of the risks within the network.Figure 4
Initial Farmer diagram of the tramway project.


### 5.3.2. Advanced Network Analysis

Several types of advanced techniques can be used. We distinguish here topological analysis, based on the static analysis of a snapshot of the network [89–91], based on topological indicators, like centrality, eigenvalues, betweenness [57], and propagation analysis, based on the dynamic simulation of potential behavior of the network [56, 92–95]. Both can help to estimate what we call Collective Importance of the risk, which is the contribution of the risk to the global behavior of the network. It depends on the position of the risk in the network and on the nature of the network.For instance, a risk with multiple direct and indirect effects will be considered as more important than an isolated risk (with no consequence except its direct impact), at an equal level of Individual Importance, since it may trigger the occurrence of impacts related to other risks in a propagation chain.In the tramway project example (Figure5), risks in red have a stronger contribution to the network behavior than other risks, independent of their individual value. Red triangles at the top of the figure (risks R49, R27, R16, and R19) are sources, meaning that they do not necessarily have a high individual criticality (between 1 and 36, 81 being the maximal value), albeit they have strong indirect consequences. Red diamonds (risks R10, R13, R39, and R12) have multiple indirect causes and multiple indirect effects. They act as hubs in the network. This is particularly dangerous when it propagates a failure from one part of the project (i.e., train design) to another part of the project (Civil Work construction), which is the case of R12. Finally, red triangles at the bottom of the figure (R2, R43, R52, and R55) are accumulation risks, meaning that they have numerous causes. An interesting point here is that three of them were not in the initial list (without complementary CST-based activity), albeit their title gives an idea about their importance (respectively, “return profit decrease,” “reengineering/redesign,” and “available cash flow decrease,”). A feedback from managers was that of course these risks were implicitly considered; however they did not know about the quantity and the complex nature of relationships between these risks and the rest of the project.Figure 5
Illustration of a network theory-based analysis of project risk interdependence.


### 5.3.3. Agile Risk Network Analysis

On the opposite of classical management styles, there is a role that coordinates this phase, called Risk Owner, albeit he/she does not have the authority for assigning members to actions. They decide, with discussion and sometimes votes, what items are included in the risk sprint backlog, under the supervision of the Risk Owner (which is a transposition to risks of the classical Product Owner role).To assist this collective prioritization step, a new type of risk diagram is proposed. It still combines Individual Importance (the individual criticality) and Collective Importance (Figure6). This means that, in this new complementary diagram, a risk will be considered as critical if and only if it is individually critical and collectively critical. This is an originality compared to classical Farmer diagram, where a risk is considered as critical if it is individually critical.Figure 6
Illustration of an original Farmer-like diagram combining Individual and Collective Importance of risks.Tramway project is illustrated in Figure6. Just as in classical Farmer diagrams, or heat map matrices, a grid is defined in order to distinguish priority levels. This is generally done using different colors. Let us call Individual Importance II and Collective Importance CI. In Figure 6, we can see that the cell with II = 1 and CI = 5 is red and the one with II = 5 and CI = 1 is yellow. So, R10 “travel time performance” will have a red priority, albeit, in classical analysis based on individual criticality only, it would have been considered as negligible (II = 1). On the opposite, risk R3 “vehicle storage in another city” has a strong individual criticality and would have been in the top priority in classical risk analysis. In our case, this is balanced with contribution to the rest of the network. Since R3 is in a yellow cell, R10, albeit less critical individually speaking, will have a higher priority at the end of the CST-based analysis.Finally, following APM-based principles, a risk backlog is created in the Kanban, entitled “Needs decision.” The risk backlog is treated as a queue, with resources being assigned to response actions depending on the place of the risk in this queue.In order to help prioritizing risks, a popular and collective tool in agility is the vote, either binary or weighted, for instance, using the Fibonacci series. Voting is not necessary for all risks, albeit beneficial for three difficult situations: 1/in case of indifference, or proximity of two risks, for instance, in the same cell of Figure6 matrix, or in neighbor cells, since we know that assessment lacks precision; 2/in case of incomparability, when two risks have the same color but are completely different, like R22 “potential risks of claim from Civil Work subcontractor” and R3 “vehicle storage in another city” in Figure 6; 3/in case of differences of perception between actors, because a risk does not have the same impact on every actor. Indeed, actors vote according to their own perception, depending on their own vulnerability to each specific risk. The concept of ordered waiting queue is important in agility, since it gives an idea of priorities. The next section introduces the phase of risk response planning, with contributions coming from CST and APM.


## 5.3.1. Classical Individual Risk Analysis

Basic risk analysis consists in prioritizing risks according to their individual criticality, generally defined as the product of probability and impact. The higher the criticality is, the more important the risk is. This is what we callIndividual Importance of the risk, i.e., the impact that the risk may have and if it occurs, all things become equal.In the tramway project, only several risks were really critical (top-right quarter of the Farmer diagram of Figure4). A lot of them have a high likelihood but weak impact (top-left quarter of the diagram). Very few risks have a high impact and low probability (down-right quarter of Figure 4). This is in this diagonal that tradeoffs have to be made, and, for the moment, decision-makers do not face complicated situations. However, they do not have any idea with this diagram about the role, the contribution of the risks within the network.Figure 4
Initial Farmer diagram of the tramway project.


## 5.3.2. Advanced Network Analysis

Several types of advanced techniques can be used. We distinguish here topological analysis, based on the static analysis of a snapshot of the network [89–91], based on topological indicators, like centrality, eigenvalues, betweenness [57], and propagation analysis, based on the dynamic simulation of potential behavior of the network [56, 92–95]. Both can help to estimate what we call Collective Importance of the risk, which is the contribution of the risk to the global behavior of the network. It depends on the position of the risk in the network and on the nature of the network.For instance, a risk with multiple direct and indirect effects will be considered as more important than an isolated risk (with no consequence except its direct impact), at an equal level of Individual Importance, since it may trigger the occurrence of impacts related to other risks in a propagation chain.In the tramway project example (Figure5), risks in red have a stronger contribution to the network behavior than other risks, independent of their individual value. Red triangles at the top of the figure (risks R49, R27, R16, and R19) are sources, meaning that they do not necessarily have a high individual criticality (between 1 and 36, 81 being the maximal value), albeit they have strong indirect consequences. Red diamonds (risks R10, R13, R39, and R12) have multiple indirect causes and multiple indirect effects. They act as hubs in the network. This is particularly dangerous when it propagates a failure from one part of the project (i.e., train design) to another part of the project (Civil Work construction), which is the case of R12. Finally, red triangles at the bottom of the figure (R2, R43, R52, and R55) are accumulation risks, meaning that they have numerous causes. An interesting point here is that three of them were not in the initial list (without complementary CST-based activity), albeit their title gives an idea about their importance (respectively, “return profit decrease,” “reengineering/redesign,” and “available cash flow decrease,”). A feedback from managers was that of course these risks were implicitly considered; however they did not know about the quantity and the complex nature of relationships between these risks and the rest of the project.Figure 5
Illustration of a network theory-based analysis of project risk interdependence.


## 5.3.3. Agile Risk Network Analysis

On the opposite of classical management styles, there is a role that coordinates this phase, called Risk Owner, albeit he/she does not have the authority for assigning members to actions. They decide, with discussion and sometimes votes, what items are included in the risk sprint backlog, under the supervision of the Risk Owner (which is a transposition to risks of the classical Product Owner role).To assist this collective prioritization step, a new type of risk diagram is proposed. It still combines Individual Importance (the individual criticality) and Collective Importance (Figure6). This means that, in this new complementary diagram, a risk will be considered as critical if and only if it is individually critical and collectively critical. This is an originality compared to classical Farmer diagram, where a risk is considered as critical if it is individually critical.Figure 6
Illustration of an original Farmer-like diagram combining Individual and Collective Importance of risks.Tramway project is illustrated in Figure6. Just as in classical Farmer diagrams, or heat map matrices, a grid is defined in order to distinguish priority levels. This is generally done using different colors. Let us call Individual Importance II and Collective Importance CI. In Figure 6, we can see that the cell with II = 1 and CI = 5 is red and the one with II = 5 and CI = 1 is yellow. So, R10 “travel time performance” will have a red priority, albeit, in classical analysis based on individual criticality only, it would have been considered as negligible (II = 1). On the opposite, risk R3 “vehicle storage in another city” has a strong individual criticality and would have been in the top priority in classical risk analysis. In our case, this is balanced with contribution to the rest of the network. Since R3 is in a yellow cell, R10, albeit less critical individually speaking, will have a higher priority at the end of the CST-based analysis.Finally, following APM-based principles, a risk backlog is created in the Kanban, entitled “Needs decision.” The risk backlog is treated as a queue, with resources being assigned to response actions depending on the place of the risk in this queue.In order to help prioritizing risks, a popular and collective tool in agility is the vote, either binary or weighted, for instance, using the Fibonacci series. Voting is not necessary for all risks, albeit beneficial for three difficult situations: 1/in case of indifference, or proximity of two risks, for instance, in the same cell of Figure6 matrix, or in neighbor cells, since we know that assessment lacks precision; 2/in case of incomparability, when two risks have the same color but are completely different, like R22 “potential risks of claim from Civil Work subcontractor” and R3 “vehicle storage in another city” in Figure 6; 3/in case of differences of perception between actors, because a risk does not have the same impact on every actor. Indeed, actors vote according to their own perception, depending on their own vulnerability to each specific risk. The concept of ordered waiting queue is important in agility, since it gives an idea of priorities. The next section introduces the phase of risk response planning, with contributions coming from CST and APM.


## 6. Sprint Planning Part 2: Agile Decisions about Interdependent Risks

In this section, two strategies are presented. First, a response plan is elaborated, consisting of a set of interdependent actions. These actions are undertaken using the current project organization. Second, the organization is reshuffled, putting together connected actors (since the risks that they, respectively, manage are interdependent). The aim is to foster coordination between interdependent actors, without knowing actions that they will undertake. Both strategies are complementary and may be implemented separately or together.


### 6.1. Strategy #1: CST-Based Risk Response Planning

Risk treatment or response planning is the process of selecting actions to reduce global risk exposure at minimal cost. We callrisk response action (RRA) an action undertaken to treat a risk. This is different from project actions (called tasks or activities). Indeed, RRA does not directly contribute to project advancement but contribute to protecting the latter against negative impacts of risks or seizing opportunities.


#### 6.1.1. Identification of Actions and Their Interdependencies

Classical RRA identification is generally based on the most critical risks, i.e., those with the highest Individual Importance. Classical RRA families are avoidance, transfer, mitigation, and acceptance. RRAs are included in a table, with information about their impact (on risks), their resources, and their schedule. In our case, there are two main differences.First, since we take into account the complex nature of the project, several original decisions are possible. It is possible to focus on nodes (risks) with high Collective Importance (influence on network behavior), independent of their individual criticality. For instance, for a risk with multiple effects, it may be better to direct efforts towards preventing this risk, rather than preventing its consequences, even if its Individual Importance is low. Indeed, it is often preferable to treat the root cause rather than the symptoms. Another strategy can be to assign this risk to another actor, in order to get a better profile for managing numerous interfaces, or to reduce the number of actors involved in a propagation chain. Then, we may act on strong interdependencies, to act on consequences of the risk rather than on the risk itself. This is equivalent to confinement strategies in, for instance, nuclear area; if we cannot avoid the event (explosion), then we try to avoid its consequences (leak in the atmosphere).Second, the risk network may help identify interdependencies between RRAs. This could take different forms, like synergy, cannibalization, impact sharing, or resource sharing, but the information is that these two actions are related to each other. Sometimes, one action blocks the other one, sometimes they cannot be run in parallel since they mobilize the same resource, and sometimes it is preferable to run them in parallel since their effects will be combined.The APM principle here is to use once again the concept of backlog. Just as risks in previous step, actions will be put in a specific list in the Kanban. The two contributions of this step are, first, to have original actions compared to a classical risk response plan (since they are inspired by the complex nature of risk network), and second to have a list of interdependencies between actions.


#### 6.1.2. Interdependent RRA Assessment

A basic estimation of actions is done, to get an estimate of their cost, duration, and human and material resource needs, just as for basic project actions.CST-based additional assessment consists in estimating the interdependence between two actions. For instance, given a block-like sequential relationship, would there be a positive or negative lag between these actions? If it is a resource sharing interdependence, do we know the consumption percentage of this resource for each action? Is there a possibility of leveling resource in order to run both actions in parallel?Then, based on previous inputs about actions and action interdependency assessments, an analysis is made in order to prioritize RRAs.


#### 6.1.3. Interdependent RRA Analysis

Classical analysis considers the impact of actions, for measuring future effectiveness (actual impact versus target) and efficiency (actual impact versus actual effort to get this impact).Considering CST, as for the risks, actions may have one or several direct impacts on one or several risks, positive and/or negative, and indirect impacts due to the interdependencies between risks and between them. So, the assessment of their impact should also include indirect impacts, using the same propagation anticipation tools compared to risk analysis. Once again, an action impacting a source risk (which is at the origin of numerous indirect consequences) may be considered as more important than an action with a similar impact but on an isolated risk.A third list is created in the Kanban, called “Response backlog.” Actions in this list may have interdependencies with risks and with each other. The next step is to make decisions to know which actions will be undertaken and which will remain for the moment in the backlog.


#### 6.1.4. Risk Response Plan Decision-Making

Classical risk response planning uses more or less formalized decision-making process, with some multicriteria consideration, e.g., with a weighted aggregation of impact versus cost.CST thus provides two improvements: 1/a classical decision-making strategy, but with an upgraded network-based version of risk analysis [49, 50], and 2/a more original strategy, considering actions interdependencies [50]. This is aimed at increasing global effectiveness and efficiency of risk response plan, notably by considering compatibility or incompatibility between the actions that are assembled in this plan.Once decisions are made, actions are moved to a new list in the Kanban, called “Ongoing actions.” They correspond to the actions that will be carried out during the sprint. Simultaneously, risks impacted by these actions move themselves to another list in the Kanban, called “Ongoing risks.”


### 6.2. Alternative Complementary Risk Response: Forming Risk Clusters to Reorganize Team Members’ Interactions

The second strategy consists in aligning organization to complexity. If complexity cannot be reduced, by mitigating critical nodes or edges, then coordination between actors who manage these nodes and edges may be improved. In classical PRM, risks are organized according to a criterion, either type of risk, department, Risk Owner, geographical site, or project phase.An original CST-based strategy consists in proposing an alternative classification, based on interdependencies and network structure, in order to adapt the organization to the complexity of the project, without changing this complexity [96, 97]. Clusters are built using more or less sophisticated algorithms, from basic heuristics to more advanced optimization algorithms. They propose maximizing the amount of risk interdependencies within clusters. Unlike classical approaches, the reason why risks are put together in the same cluster is not because they are similar or contribute to the same objective, but because they are strongly interdependent. This allows actors to know which interdependencies they have with other actors within the cluster.Tramway project is shown in Figure7, with decreasing values for red, dark green, and light green cells. The most interesting clusters are those with multiple red and dark green cells. Decision-makers decided to implement only four of the proposed clusters, those with highest relevance (the four biggest ones).Figure 7
Illustration of the proposed clusters in the tramway project example.The team has the possibility of managing risks as a whole (team level) or at a more precise level (cluster level), with less actors and less but connected risks. A new list is inserted in the Kanban, called “Risk clusters,” where each card corresponds to a cluster. This means that several risks are assigned to each cluster. It is the object of next section to introduce how planned things are executed, still using agile principles.


## 6.1. Strategy #1: CST-Based Risk Response Planning

Risk treatment or response planning is the process of selecting actions to reduce global risk exposure at minimal cost. We callrisk response action (RRA) an action undertaken to treat a risk. This is different from project actions (called tasks or activities). Indeed, RRA does not directly contribute to project advancement but contribute to protecting the latter against negative impacts of risks or seizing opportunities.


### 6.1.1. Identification of Actions and Their Interdependencies

Classical RRA identification is generally based on the most critical risks, i.e., those with the highest Individual Importance. Classical RRA families are avoidance, transfer, mitigation, and acceptance. RRAs are included in a table, with information about their impact (on risks), their resources, and their schedule. In our case, there are two main differences.First, since we take into account the complex nature of the project, several original decisions are possible. It is possible to focus on nodes (risks) with high Collective Importance (influence on network behavior), independent of their individual criticality. For instance, for a risk with multiple effects, it may be better to direct efforts towards preventing this risk, rather than preventing its consequences, even if its Individual Importance is low. Indeed, it is often preferable to treat the root cause rather than the symptoms. Another strategy can be to assign this risk to another actor, in order to get a better profile for managing numerous interfaces, or to reduce the number of actors involved in a propagation chain. Then, we may act on strong interdependencies, to act on consequences of the risk rather than on the risk itself. This is equivalent to confinement strategies in, for instance, nuclear area; if we cannot avoid the event (explosion), then we try to avoid its consequences (leak in the atmosphere).Second, the risk network may help identify interdependencies between RRAs. This could take different forms, like synergy, cannibalization, impact sharing, or resource sharing, but the information is that these two actions are related to each other. Sometimes, one action blocks the other one, sometimes they cannot be run in parallel since they mobilize the same resource, and sometimes it is preferable to run them in parallel since their effects will be combined.The APM principle here is to use once again the concept of backlog. Just as risks in previous step, actions will be put in a specific list in the Kanban. The two contributions of this step are, first, to have original actions compared to a classical risk response plan (since they are inspired by the complex nature of risk network), and second to have a list of interdependencies between actions.


### 6.1.2. Interdependent RRA Assessment

A basic estimation of actions is done, to get an estimate of their cost, duration, and human and material resource needs, just as for basic project actions.CST-based additional assessment consists in estimating the interdependence between two actions. For instance, given a block-like sequential relationship, would there be a positive or negative lag between these actions? If it is a resource sharing interdependence, do we know the consumption percentage of this resource for each action? Is there a possibility of leveling resource in order to run both actions in parallel?Then, based on previous inputs about actions and action interdependency assessments, an analysis is made in order to prioritize RRAs.


### 6.1.3. Interdependent RRA Analysis

Classical analysis considers the impact of actions, for measuring future effectiveness (actual impact versus target) and efficiency (actual impact versus actual effort to get this impact).Considering CST, as for the risks, actions may have one or several direct impacts on one or several risks, positive and/or negative, and indirect impacts due to the interdependencies between risks and between them. So, the assessment of their impact should also include indirect impacts, using the same propagation anticipation tools compared to risk analysis. Once again, an action impacting a source risk (which is at the origin of numerous indirect consequences) may be considered as more important than an action with a similar impact but on an isolated risk.A third list is created in the Kanban, called “Response backlog.” Actions in this list may have interdependencies with risks and with each other. The next step is to make decisions to know which actions will be undertaken and which will remain for the moment in the backlog.


### 6.1.4. Risk Response Plan Decision-Making

Classical risk response planning uses more or less formalized decision-making process, with some multicriteria consideration, e.g., with a weighted aggregation of impact versus cost.CST thus provides two improvements: 1/a classical decision-making strategy, but with an upgraded network-based version of risk analysis [49, 50], and 2/a more original strategy, considering actions interdependencies [50]. This is aimed at increasing global effectiveness and efficiency of risk response plan, notably by considering compatibility or incompatibility between the actions that are assembled in this plan.Once decisions are made, actions are moved to a new list in the Kanban, called “Ongoing actions.” They correspond to the actions that will be carried out during the sprint. Simultaneously, risks impacted by these actions move themselves to another list in the Kanban, called “Ongoing risks.”


## 6.1.1. Identification of Actions and Their Interdependencies

Classical RRA identification is generally based on the most critical risks, i.e., those with the highest Individual Importance. Classical RRA families are avoidance, transfer, mitigation, and acceptance. RRAs are included in a table, with information about their impact (on risks), their resources, and their schedule. In our case, there are two main differences.First, since we take into account the complex nature of the project, several original decisions are possible. It is possible to focus on nodes (risks) with high Collective Importance (influence on network behavior), independent of their individual criticality. For instance, for a risk with multiple effects, it may be better to direct efforts towards preventing this risk, rather than preventing its consequences, even if its Individual Importance is low. Indeed, it is often preferable to treat the root cause rather than the symptoms. Another strategy can be to assign this risk to another actor, in order to get a better profile for managing numerous interfaces, or to reduce the number of actors involved in a propagation chain. Then, we may act on strong interdependencies, to act on consequences of the risk rather than on the risk itself. This is equivalent to confinement strategies in, for instance, nuclear area; if we cannot avoid the event (explosion), then we try to avoid its consequences (leak in the atmosphere).Second, the risk network may help identify interdependencies between RRAs. This could take different forms, like synergy, cannibalization, impact sharing, or resource sharing, but the information is that these two actions are related to each other. Sometimes, one action blocks the other one, sometimes they cannot be run in parallel since they mobilize the same resource, and sometimes it is preferable to run them in parallel since their effects will be combined.The APM principle here is to use once again the concept of backlog. Just as risks in previous step, actions will be put in a specific list in the Kanban. The two contributions of this step are, first, to have original actions compared to a classical risk response plan (since they are inspired by the complex nature of risk network), and second to have a list of interdependencies between actions.


## 6.1.2. Interdependent RRA Assessment

A basic estimation of actions is done, to get an estimate of their cost, duration, and human and material resource needs, just as for basic project actions.CST-based additional assessment consists in estimating the interdependence between two actions. For instance, given a block-like sequential relationship, would there be a positive or negative lag between these actions? If it is a resource sharing interdependence, do we know the consumption percentage of this resource for each action? Is there a possibility of leveling resource in order to run both actions in parallel?Then, based on previous inputs about actions and action interdependency assessments, an analysis is made in order to prioritize RRAs.


## 6.1.3. Interdependent RRA Analysis

Classical analysis considers the impact of actions, for measuring future effectiveness (actual impact versus target) and efficiency (actual impact versus actual effort to get this impact).Considering CST, as for the risks, actions may have one or several direct impacts on one or several risks, positive and/or negative, and indirect impacts due to the interdependencies between risks and between them. So, the assessment of their impact should also include indirect impacts, using the same propagation anticipation tools compared to risk analysis. Once again, an action impacting a source risk (which is at the origin of numerous indirect consequences) may be considered as more important than an action with a similar impact but on an isolated risk.A third list is created in the Kanban, called “Response backlog.” Actions in this list may have interdependencies with risks and with each other. The next step is to make decisions to know which actions will be undertaken and which will remain for the moment in the backlog.


## 6.1.4. Risk Response Plan Decision-Making

Classical risk response planning uses more or less formalized decision-making process, with some multicriteria consideration, e.g., with a weighted aggregation of impact versus cost.CST thus provides two improvements: 1/a classical decision-making strategy, but with an upgraded network-based version of risk analysis [49, 50], and 2/a more original strategy, considering actions interdependencies [50]. This is aimed at increasing global effectiveness and efficiency of risk response plan, notably by considering compatibility or incompatibility between the actions that are assembled in this plan.Once decisions are made, actions are moved to a new list in the Kanban, called “Ongoing actions.” They correspond to the actions that will be carried out during the sprint. Simultaneously, risks impacted by these actions move themselves to another list in the Kanban, called “Ongoing risks.”


## 6.2. Alternative Complementary Risk Response: Forming Risk Clusters to Reorganize Team Members’ Interactions

The second strategy consists in aligning organization to complexity. If complexity cannot be reduced, by mitigating critical nodes or edges, then coordination between actors who manage these nodes and edges may be improved. In classical PRM, risks are organized according to a criterion, either type of risk, department, Risk Owner, geographical site, or project phase.An original CST-based strategy consists in proposing an alternative classification, based on interdependencies and network structure, in order to adapt the organization to the complexity of the project, without changing this complexity [96, 97]. Clusters are built using more or less sophisticated algorithms, from basic heuristics to more advanced optimization algorithms. They propose maximizing the amount of risk interdependencies within clusters. Unlike classical approaches, the reason why risks are put together in the same cluster is not because they are similar or contribute to the same objective, but because they are strongly interdependent. This allows actors to know which interdependencies they have with other actors within the cluster.Tramway project is shown in Figure7, with decreasing values for red, dark green, and light green cells. The most interesting clusters are those with multiple red and dark green cells. Decision-makers decided to implement only four of the proposed clusters, those with highest relevance (the four biggest ones).Figure 7
Illustration of the proposed clusters in the tramway project example.The team has the possibility of managing risks as a whole (team level) or at a more precise level (cluster level), with less actors and less but connected risks. A new list is inserted in the Kanban, called “Risk clusters,” where each card corresponds to a cluster. This means that several risks are assigned to each cluster. It is the object of next section to introduce how planned things are executed, still using agile principles.


## 7. Risk Scrum-like Meetings to Improve Daily Execution of Planned Risk Response

This section introduces the transposition of Scrum meeting concept applied to CST-based PRM.


### 7.1. Specificities of an Agile Daily Risk Meeting

A key principle of APM and notably Scrum methodology is to run daily meetings, where project team members exchange about their past realizations, future realizations, and potential obstacles [98]. It is supposed to take at most 15 minutes, is usually done on a standing mode, and is animated by the Scrum Master, which is the other specific role of Scrum methodology. Product Owner and Scrum Master replace the traditional project manager, splitting responsibilities into two different roles necessarily assigned to different persons. This means that, during the sprint, the Product Owner does not have authority on what the team does or how. He/she can participate as a contributor to tasks. The Scrum Master does not have authority over the team either. This role is a facilitator role, aiming at capturing and processing potential tensions, obstacles, or problems that reduce the team performance, called velocity.In our case, we identify two possibilities: either integrating risk meetings in general project meetings or running them as specific, separate meetings. In the first case, global time has to be kept under control, and it may be animated by the same person, the Scrum Master. The difference is that he/she has to simultaneously integrate information about project tasks and risk response actions, which may bring some confusion or repetition.This is why we prefer splitting meetings in two. Benefits are threefold. First, as explained before, it avoids confusion between the different types of actions and risks that people are talking about. Second, it enables a similar duration to be attributed to a specific risk Scrum meeting, possibly with a different frequency, given that people have generally neither full-time nor daily management of their risk response actions. Third, another person could be involved, a specific Risk Scrum Master.How these meetings are run using CST is also a bit different. The same structure is kept, that is to say, giving information about recent advancements, future short-term advancements, and potential obstacles. Even the standing concept can be retained. However, it is preferable to display specific CST information, such as risk network, risk clusters, or team interdependencies, due to the importance of visualization on such complex subjects. A last possibility is to run specific meetings by clusters, since it is where most interdependencies are together.In order to distinguish risks and actions with different status, the meeting is split into several parts, respectively, talking about current status and future corrections.


### 7.2. Part 1: Project Status (in terms of Risk Management)

Three elements are analyzed here, the response actions, the risks, and the clusters.


#### 7.2.1. Status of Risk Response Actions

In our context, risk Scrum meeting first presents the advancement of risk response actions (Figure8). In the tramway project example, several data are available in the Action Card (Figure 8):(1)
ActionA12 is assigned to risk R30(2)
Actor 1 is the action owner(3)
Action cost is 20 (k€ here)(4)
The strategy is to avoid riskR30, meaning that probability of R30 is supposed to be reduced to 0(5)
ActionA12 comes from Individual Criticality Analysis, meaning that this is the Individual Importance of risk R30 that justified the inclusion of A12 in the operational backlog(6)
A12 blocks action A18, meaning that the latter needs an output, an information, or a resource that is not available until A12 is finishedFigure 8
Status of a specific risk response actionA12.


#### 7.2.2. Status of Risks (Update of Existing Values Depending on Advancement of Response Strategies)

Moreover, key information about risk is available on a single support, the Risk Card (Figure9):(1)
The title of the risk (here riskR10)(2)
The Risk Owner (actor 4)(3)
The risk cluster (if applicable) hereR10 belongs to cluster #1(4)
The status: ongoing, meaning that the risk is not treated yet, but an action is ongoing(5)
The dependencies with other risks (R10 is related to R2, R47, and R44)(6)
The dependencies with actions that have been identified to impactR10 (A18 and A14)Figure 9
Status of a specific riskR10.


#### 7.2.3. Status of Risk Clusters

For the Risk Kanban tool, clusters are modeled as epics in a specific list, on the right side of Risk Kanban in the background of Figure10. This means that when risks are treated (moved to the corresponding list in the Kanban, on the left in the background of Figure 10), the corresponding cluster card is automatically updated. People can monitor the status of the whole cluster, knowing that, for instance, 3 risks are already treated and 6 remain open (see example of cluster #2 of tramway project in the middle of Figure 10).Figure 10
Follow-up for cluster 2 of the 9 risks included in this cluster.


### 7.3. Part 2: Updates and Decisions

There may be new information about risks, independent of existing actions plan, and thus the need to run or modify actions.


#### 7.3.1. Risk Update

It is possible to add new elements, to remove elements, to move elements (change their status, their position in the list, or their list in the Kanban), and to update elements (their parameters, like probability, impact, interdependencies, actor, etc.). This is where the higher frequency for such meetings has its importance, since this kind of risk update is classically done during risk reviews, with a monthly rhythm. It is a quite long meeting, with systematic analysis of each element in the list (several tens to several hundreds of elements). In our case, it has to remain quick, and there are each day generally only few changes, so the steps are quicker, and meetings are more fluid and diverse.


#### 7.3.2. Update of Response Strategies (Response Plan and Clusters)

Depending on highlights of part 1 analysis and new risks emerging from previous step, an update of the risk response plan may be necessary. Principles are identical to what has been done in sprint planning. Then, this short, frequent controlling process is complementary to a more classical risk review, detailed in the next paragraph.


## 7.1. Specificities of an Agile Daily Risk Meeting

A key principle of APM and notably Scrum methodology is to run daily meetings, where project team members exchange about their past realizations, future realizations, and potential obstacles [98]. It is supposed to take at most 15 minutes, is usually done on a standing mode, and is animated by the Scrum Master, which is the other specific role of Scrum methodology. Product Owner and Scrum Master replace the traditional project manager, splitting responsibilities into two different roles necessarily assigned to different persons. This means that, during the sprint, the Product Owner does not have authority on what the team does or how. He/she can participate as a contributor to tasks. The Scrum Master does not have authority over the team either. This role is a facilitator role, aiming at capturing and processing potential tensions, obstacles, or problems that reduce the team performance, called velocity.In our case, we identify two possibilities: either integrating risk meetings in general project meetings or running them as specific, separate meetings. In the first case, global time has to be kept under control, and it may be animated by the same person, the Scrum Master. The difference is that he/she has to simultaneously integrate information about project tasks and risk response actions, which may bring some confusion or repetition.This is why we prefer splitting meetings in two. Benefits are threefold. First, as explained before, it avoids confusion between the different types of actions and risks that people are talking about. Second, it enables a similar duration to be attributed to a specific risk Scrum meeting, possibly with a different frequency, given that people have generally neither full-time nor daily management of their risk response actions. Third, another person could be involved, a specific Risk Scrum Master.How these meetings are run using CST is also a bit different. The same structure is kept, that is to say, giving information about recent advancements, future short-term advancements, and potential obstacles. Even the standing concept can be retained. However, it is preferable to display specific CST information, such as risk network, risk clusters, or team interdependencies, due to the importance of visualization on such complex subjects. A last possibility is to run specific meetings by clusters, since it is where most interdependencies are together.In order to distinguish risks and actions with different status, the meeting is split into several parts, respectively, talking about current status and future corrections.


## 7.2. Part 1: Project Status (in terms of Risk Management)

Three elements are analyzed here, the response actions, the risks, and the clusters.


### 7.2.1. Status of Risk Response Actions

In our context, risk Scrum meeting first presents the advancement of risk response actions (Figure8). In the tramway project example, several data are available in the Action Card (Figure 8):(1)
ActionA12 is assigned to risk R30(2)
Actor 1 is the action owner(3)
Action cost is 20 (k€ here)(4)
The strategy is to avoid riskR30, meaning that probability of R30 is supposed to be reduced to 0(5)
ActionA12 comes from Individual Criticality Analysis, meaning that this is the Individual Importance of risk R30 that justified the inclusion of A12 in the operational backlog(6)
A12 blocks action A18, meaning that the latter needs an output, an information, or a resource that is not available until A12 is finishedFigure 8
Status of a specific risk response actionA12.


### 7.2.2. Status of Risks (Update of Existing Values Depending on Advancement of Response Strategies)

Moreover, key information about risk is available on a single support, the Risk Card (Figure9):(1)
The title of the risk (here riskR10)(2)
The Risk Owner (actor 4)(3)
The risk cluster (if applicable) hereR10 belongs to cluster #1(4)
The status: ongoing, meaning that the risk is not treated yet, but an action is ongoing(5)
The dependencies with other risks (R10 is related to R2, R47, and R44)(6)
The dependencies with actions that have been identified to impactR10 (A18 and A14)Figure 9
Status of a specific riskR10.


### 7.2.3. Status of Risk Clusters

For the Risk Kanban tool, clusters are modeled as epics in a specific list, on the right side of Risk Kanban in the background of Figure10. This means that when risks are treated (moved to the corresponding list in the Kanban, on the left in the background of Figure 10), the corresponding cluster card is automatically updated. People can monitor the status of the whole cluster, knowing that, for instance, 3 risks are already treated and 6 remain open (see example of cluster #2 of tramway project in the middle of Figure 10).Figure 10
Follow-up for cluster 2 of the 9 risks included in this cluster.


## 7.2.1. Status of Risk Response Actions

In our context, risk Scrum meeting first presents the advancement of risk response actions (Figure8). In the tramway project example, several data are available in the Action Card (Figure 8):(1)
ActionA12 is assigned to risk R30(2)
Actor 1 is the action owner(3)
Action cost is 20 (k€ here)(4)
The strategy is to avoid riskR30, meaning that probability of R30 is supposed to be reduced to 0(5)
ActionA12 comes from Individual Criticality Analysis, meaning that this is the Individual Importance of risk R30 that justified the inclusion of A12 in the operational backlog(6)
A12 blocks action A18, meaning that the latter needs an output, an information, or a resource that is not available until A12 is finishedFigure 8
Status of a specific risk response actionA12.


## 7.2.2. Status of Risks (Update of Existing Values Depending on Advancement of Response Strategies)

Moreover, key information about risk is available on a single support, the Risk Card (Figure9):(1)
The title of the risk (here riskR10)(2)
The Risk Owner (actor 4)(3)
The risk cluster (if applicable) hereR10 belongs to cluster #1(4)
The status: ongoing, meaning that the risk is not treated yet, but an action is ongoing(5)
The dependencies with other risks (R10 is related to R2, R47, and R44)(6)
The dependencies with actions that have been identified to impactR10 (A18 and A14)Figure 9
Status of a specific riskR10.


## 7.2.3. Status of Risk Clusters

For the Risk Kanban tool, clusters are modeled as epics in a specific list, on the right side of Risk Kanban in the background of Figure10. This means that when risks are treated (moved to the corresponding list in the Kanban, on the left in the background of Figure 10), the corresponding cluster card is automatically updated. People can monitor the status of the whole cluster, knowing that, for instance, 3 risks are already treated and 6 remain open (see example of cluster #2 of tramway project in the middle of Figure 10).Figure 10
Follow-up for cluster 2 of the 9 risks included in this cluster.


## 7.3. Part 2: Updates and Decisions

There may be new information about risks, independent of existing actions plan, and thus the need to run or modify actions.


### 7.3.1. Risk Update

It is possible to add new elements, to remove elements, to move elements (change their status, their position in the list, or their list in the Kanban), and to update elements (their parameters, like probability, impact, interdependencies, actor, etc.). This is where the higher frequency for such meetings has its importance, since this kind of risk update is classically done during risk reviews, with a monthly rhythm. It is a quite long meeting, with systematic analysis of each element in the list (several tens to several hundreds of elements). In our case, it has to remain quick, and there are each day generally only few changes, so the steps are quicker, and meetings are more fluid and diverse.


### 7.3.2. Update of Response Strategies (Response Plan and Clusters)

Depending on highlights of part 1 analysis and new risks emerging from previous step, an update of the risk response plan may be necessary. Principles are identical to what has been done in sprint planning. Then, this short, frequent controlling process is complementary to a more classical risk review, detailed in the next paragraph.


## 7.3.1. Risk Update

It is possible to add new elements, to remove elements, to move elements (change their status, their position in the list, or their list in the Kanban), and to update elements (their parameters, like probability, impact, interdependencies, actor, etc.). This is where the higher frequency for such meetings has its importance, since this kind of risk update is classically done during risk reviews, with a monthly rhythm. It is a quite long meeting, with systematic analysis of each element in the list (several tens to several hundreds of elements). In our case, it has to remain quick, and there are each day generally only few changes, so the steps are quicker, and meetings are more fluid and diverse.


## 7.3.2. Update of Response Strategies (Response Plan and Clusters)

Depending on highlights of part 1 analysis and new risks emerging from previous step, an update of the risk response plan may be necessary. Principles are identical to what has been done in sprint planning. Then, this short, frequent controlling process is complementary to a more classical risk review, detailed in the next paragraph.


## 8. Sprint Reviews for Risk Monitoring and Control

At the end of each sprint, two specific meetings are run. The first one is sprint review, in which sprint results are systematically inspected by project stakeholders. The customer (external or internal) may be present. The aim is to visualize results rather than to discuss project-based information, like planning and budgets.In our context, the sprint risk review is aimed at screening the status of the whole risk and risk response actions Kanban tools.The latter is quite classical in terms of agile methodologies, with four states displayed in Figure11 (from right to left):(1)
Action list #1: backlog (to be started)(2)
Action list #2: ongoing (started)(3)
Action list #3: it needs review/correction (started but with a status that requires a specific action)(4)
Action list #4: done (finished or cancelled)Figure 11
Example of a risk response actions Kanban tool, showing the different states of actions lifecycle.Figure11 also shows assignment of actors to actions. Only one actor is assigned to the action, as the action owner, even if several members, can contribute to it.The Risk Kanban is split into four lists corresponding to the progression of risk into the PRM process (Figure12, from right to left):(1)
Risk list #1: risks are identified and thus need to be assessed and analyzed(2)
Risk list #2: risks are analyzed and prioritized; a decision has to be made(3)
Risk list #3: a decision has been made; the risk is ongoing, meaning that at least one action is ongoing to treat it or that it has been accepted (decision to do nothing)(4)
Risk list #4: when risk is treated or is in a time window when it cannot occur, it is included in this fourth list, meaning that no action is required (at least for the moment)Figure 12
Example of a Risk Kanban tool, showing the different states of risks throughout their lifecycle.The first two lists are elaborated during sprint planning, and once decisions are made, risks become in an active phase, either ongoing or treated. “Inactive” in Figure12 means that the risk is no longer active for the moment (not an adequate time window). An illustration on the tramway project is given, with assignments of actors to risks (they are called Risk Owners).Sprint reviews are more at the team level; clusters are more suitable for meetings during the sprint.There is no originality compared to APM, except that risk exposure is considered as result of the sprint. The information about potential changes for the next sprint is not collected here but are the object of next sprint planning meeting.


## 9. Sprint Retrospective Meetings for Upgrading Lessons Learnt and Risk Management Principles

The last phase in PRM, called “lessons learnt,” is aimed at capturing experience about the project, notably knowing whether or not the risks of this project can be reused for another project.APM proposes a specific meeting at the end of each sprint, dedicated to discussion about how things have been conducted and what could be improved. This is called sprint retrospective and it is deliberately separated from sprint review, the formal follow-up of advancement, and delivery of results. Two steps of PRM can benefit from such a specific meeting. The sprint retrospective is run between sprint review and the next sprint planning meetings, in order to let the team discuss on how things went during previous sprint and possibly propose some improvements [99].In the basic PRM process, lessons learnt (or return on experience) are generally at the end of the project, either in the last phase or even after the end of the project. APM-based retrospective meetings allow for getting information all along the project, at the end of each sprint, about risks, actions, and clusters, for next sprint or for other projects (either in parallel or in the future).In the basic PRM process, risk management principles are established at the initiation of the project and generally not changed. Here, at each sprint retrospective, there is an opportunity to get information and to make decisions about risk management, team management, coordination, correct use of proposed CST-based, or APM-based principles and tools. This means that the team can improve its performance during the succession of sprints, which is called velocity in agile vocabulary. There is no equivalent term in PRM; however this relates to the notion of PRM performance. Do we do things efficiently, and do they have an effective impact? Is it worthy to put effort in PRM? The main advantage of APM principles application is that adjustments can be made on a regular basis.


## 10. Preliminary Results

Two experiments are ongoing, applying agile principles to improve PRM in organizations that are already using complex system-based principles (arrow 2 of Figure1). Both are big organizations (tens of thousands of people) running big projects (several hundreds of millions of dollars, several years, and hundreds of project members). Both recognized the usefulness of CST-based Project Risk Management, albeit with difficulties in implementing it properly, mostly based on human resistance and governance challenges. This work requires a lot of time to gather data, interview people, explain new principles, tools, and techniques, prototype on a part of the project and project team in order to get a kernel of “pushing people,” monitoring the correct application of both complex-based and agile principles, reinterview people, and draw conclusions at the end of each iteration. However, intermediary conclusions and perspectives can already be drawn.Preliminary results in both organizations are threefold. First, what was not really expected is the similarity of both implementation trajectories, with almost the same benefits and the same limits (or brakes). Adding more practical and distributed principles coming from agile management makes the perception of CST-based advanced techniques lighter. It helped to remove the initial resistance about fear or reluctance to use advanced tools. In doing that, it automatically reduced some issues in the way people behaved, like reluctance to contribute to risk review meetings (since decisions are now made with their input) and lack of coordination and misunderstandings (since ownership and authority are clearer now). This is the positive aspect.Second, there is appropriation by people involved to change the rhythm of meetings in one organization. 15-minute daily risk Scrum meetings became biweekly, and 1-hour monthly risk review became fortnightly. As recommended by Stray and coworkers [100], it is possible for a team to tailor methods; in fact it could even be interpreted as an expression of third agile value, adaptation to situation. For managers, it is also a good sign of appropriation by users.Third, remaining human resistance is twofold and is not directly related to introduction of CST principles into PRM. There are some company-level issues, like silos, territories, and informal networks. These concerns are more about history and culture, albeit they have of course an influence on how CST-based coordination can be correctly run. Moreover, there are individual issues about autonomy, both for managers and for members. It takes time to change habits, and not everybody can adapt and make progress.


## 11. Conclusions and Perspectives

Project Risk Management is significantly contributive to project performance and thus to supporting organization’s performance, notably in the case of complex projects where their size may put organization’s health at risk. Complex Systems Theory and Agile Project Management have been combined into an upgraded Project Risk Management approach. The global aim is to link autonomy in execution and structure in coordination: less execution rules, more coordination rules. The main intermediary result of this combination is that agile principles make CST principles lighter to understand and to apply.The overall originality of this work is to combine conceptual and managerial methodologies in order to benefit from their advantages. More precisely, an original Collective Importance in the network has been added (coming from topological and propagation analyses like in Figure5). A new two-axis Farmer-like diagram is proposed; the originality is that a risk is critical if and only if it is simultaneously critical among both axes (Figure 6). A second originality is the use of a Kanban (Figures 11 and 12) to model risks, actions, actors, and their interdependencies (risks-risks, risks-actors, risks-actions, actions-actors, and actions-actions). Third, risk clusters (Figure 7) are proposed as an intermediary level of management, with smaller, strongly connected teams (Figure 10). Fourth, a double rhythm can be adopted for monitoring and control, with the classical risk monitoring in risk reviews, and the original daily (or biweekly) Scrum risk meeting. Instead of running once “definition of principles” and “lessons learnt,” the iteration of sprints allows for capturing all along the project information about experience for other projects (and for future sprints) and for upgrading management principles since sprint retrospective is a new meeting. Fifth, accountabilities of roles contributing to PRM (often project/work package manager and risk manager, sometimes system manager) are modified to formalize interdependencies between roles and to establish some policies/strategies for managing frequency and mode of communication/coordination. Project risk sprint planning is led by the Project Risk Owner, who participates and potentially confirms inclusion and prioritization of elements in backlogs (risks in the risk backlog and response actions in the action backlog). This means that this specific risk sprint planning meeting may have to be separated from the global project sprint planning, notably to allow for another person to play the specific Project Risk Owner role.As a perspective, agility brings value, but other techniques, methodologies, and philosophies exist to implement principles for a more distributed governance. What other concepts could be mixed with agile ones? Is it possible to select principles from other methodologies, like holacracy, to tailor management principles to each context?A second perspective is to run other applications in the complementary starting point. We were contacted by companies currently running Agile Project Management. They were thinking about a more structured way, not to tell people what to do (which is contrary to one major agile value), but to identify with whom to coordinate. In this case, the question is to introduce CST principles into an organization which is mature on agility (arrow 4 of Figure1). Finally, a conceptual perspective is to model interdependencies between more than two risks, when, for instance, it is a simultaneous combination of two risks that may trigger a third one.



---

*Source: 3739129-2020-10-10.xml*