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

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 (eory-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. (is 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 (eory.


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. ese issues are all the more important since PRM performance is crucial for the performance of the projects and the organizations that support them [6][7][8][9].
is is why PRM needs to be adapted in order to integrate advanced complexity-related and alternative management principles.
is 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 eory (CST) and Agile Project Management (APM). e remainder of the paper is as follows. Section 2 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. e 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. en, Sections 10 and 11 will draw some elements of discussion, conclusion, and perspective.
ese 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. e way actors are organized and behave may also have an impact on risk identification [38].

Risk Assessment.
It consists in putting qualitative or quantitative estimates to risks, according to several parameters [39][40][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.

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]. is 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][44][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. is involves a clear issue of competence, individual bias, and versatility.

Risk Response Planning.
It is the process of selecting actions to reduce global risk exposure at minimal cost. e 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], WBSbased 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.

Risk Monitoring and Control.
e 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.

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. ird, there may be a risk of blame assigning that may prevent members for journaling what really happened.

Research Question.
is 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 commandand-control philosophy, prevented this CST-based PRM process to be undertaken with a network of actors. ere was a gap between the potential of actors' coordination and the reality, still centralized. e 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. e problem here is to introduce conceptual improvements into PRM.
As shown in Figure 1, 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). e 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.
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?

Research Approach
Mäkinen proposes in Table 1 a classification of research methodologies [51].
In 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). e evaluation step allowed us to conceptualize remaining lacks, mostly managerial. is 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).

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][56][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][59][60]. ey 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.
is 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  Agile management methodologies are based on shorter time horizons for planning and review, more flexibility on planning, and more autonomy given to members. e 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][75][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.
e 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. e 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. is is why the managerial aspect should be simultaneously considered, which is the object of the following paragraph.

Integrating Complex Systems eory (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. e 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. Table 2 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 eory assist some of these PRM subprocesses during several agile meetings.
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.

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. is 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. e first time in which these meetings are run is expected to be longer, so they are separated. After several sprints, their duration diminishes,

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

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.

Identifying Interdependencies between Risks.
Several terms exist such as interdependence, interaction, interrelation, relationship, and even interface. ey 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][83][84].
ose 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 creativitybased 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. e 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. en, 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].

Agile Risk Network Identification.
e use of APMbased principles naturally involves running this identification step as a team and not individually. e 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). is allows for prioritizing tasks and keeping list size reasonable. In our context, each risk appears as the socalled card in a list of the Kanban. is 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, R i declares an interdependency with another risk R j ; then, this tool automatically duplicates the information into R j card. en, 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 R j agree that this risk is related to risk R i , as declared by owner of R i ?).
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. is 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). ree 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. is means that there are 54 additional interdependencies involved (more than twice the initial number). As illustrated in Figure 2, 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.

Risk Network Assessment.
e second part of the process consists of assessing first risks and then their interdependencies.

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 Table 3.
Classically, this step finishes here and is directly followed by analysis. Here, a complementary CST-based assessment is made, in order to assess risk interdependencies.

Risk Interdependency Assessment.
e fact that a possible interdependency has been identified from R i to R j means that when R i occurs, there is a chance of R j occurring as well as a consequence of R i . is is called P(R j |R i ), the probability of R j knowing R i , also called conditional probability. e 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. e first one is to directly evaluate interdependencies using expert judgment. e second one is to use relative comparisons, for instance, the pairwise comparison Analytic Hierarchy Process [81,[86][87][88].

Agile Risk Network Assessment.
In the tramway project, local pairwise comparison has been used; i.e., each Risk Owner has analyzed her direct interdependencies. is 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 (R i and R j ); 2/comparing the relative strength of interdependencies, for each node with R i as origin, and each node with R j as end; 3/extracting eigenvectors of the corresponding adjacency matrix; 4/aggregating results for R i and for R j ; 5/compiling results for the R i − R j interdependency (averaging perception of interdependence with R j by R i and perception of interdependence with R i by R j ). e 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 ( Figure 3). 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.

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.

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. e higher the criticality is, the more important the risk is. is is what we call Individual 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 Figure 4). 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).
is 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.

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][90][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][93][94][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.

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. ey 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 ( Figure 6). is 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.
is is an originality compared to classical Farmer diagram, where a risk is considered as critical if it is individually critical.
Tramway project is illustrated in Figure 6. Just as in classical Farmer diagrams, or heat map matrices, a grid is defined in order to distinguish priority levels. is 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 8 Complexity with II � 5 and CI � 1 is yellow. So, R 10 "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 R 3 "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 R 3 is in a yellow cell, R 10 , 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." e 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 Figure 6 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 R 22 "potential risks of claim from Civil Work subcontractor" and R 3 "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. e concept of ordered waiting queue is important in agility, since it gives an idea of priorities. e next section introduces the phase of risk response planning, with contributions coming from CST and APM.

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 call risk response action (RRA) an action undertaken to treat a risk. is 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.

Identification of Actions and eir 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. en, we may act on strong interdependencies, to act on consequences of the risk rather than on the risk itself.
is 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. is 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. e 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. e 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   10 Complexity nature of risk network), and second to have a list of interdependencies between actions.

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? en, based on previous inputs about actions and action interdependency assessments, an analysis is made in order to prioritize RRAs.

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. e next step is to make decisions to know which actions will be undertaken and which will remain for the moment in the backlog.

Risk Response Plan Decision-Making.
Classical risk response planning uses more or less formalized decisionmaking 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 networkbased version of risk analysis [49,50], and 2/a more original strategy, considering actions interdependencies [50]. is is aimed at increasing global effectiveness and efficiency of risk response plan, notably by considering compatibility or Complexity 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." ey 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."

Alternative Complementary Risk Response: Forming Risk Clusters to Reorganize Team Members' Interactions.
e 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. ey 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.
is allows actors to know which interdependencies they have with other actors within the cluster.
Tramway project is shown in Figure 7, with decreasing values for red, dark green, and light green cells. e 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). e 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. is 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.

Risk Scrum-like Meetings to Improve Daily Execution of Planned Risk Response
is section introduces the transposition of Scrum meeting concept applied to CST-based PRM.

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. is 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. e Scrum Master does not have authority over the team either. is 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. e difference is that he/ she has to simultaneously integrate information about project tasks and risk response actions, which may bring some confusion or repetition.
is 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. ird, another person could be involved, a specific Risk Scrum Master.
How these meetings are run using CST is also a bit different. e 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.

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 ( Figure 9): (1) e title of the risk (here risk R 10 ) (2) e Risk Owner (actor 4) (3) e risk cluster (if applicable) here R 10 belongs to cluster #1 (4) e status: ongoing, meaning that the risk is not treated yet, but an action is ongoing (5) e dependencies with other risks (R 10 is related to R 2 , R 47 , and R 44 ) (6) e dependencies with actions that have been identified to impact R 10 (A 18 and A 14 )

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 Figure 10. is 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).

Part 2: Updates and Decisions.
ere may be new information about risks, independent of existing actions plan, and thus the need to run or modify actions.

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.). is 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.

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. en, this short, frequent controlling process is complementary to a more classical risk review, detailed in the next paragraph.

Sprint Reviews for Risk Monitoring and Control
At the end of each sprint, two specific meetings are run. e first one is sprint review, in which sprint results are systematically inspected by project stakeholders. e customer (external or internal) may be present. e 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. e latter is quite classical in terms of agile methodologies, with four states displayed in Figure 11 (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 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. e Risk Kanban is split into four lists corresponding to the progression of risk into the PRM process ( Figure 12, 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) e 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 Figure 12 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.
ere is no originality compared to APM, except that risk exposure is considered as result of the sprint. e information about potential changes for the next sprint is not collected here but are the object of next sprint planning meeting.

Sprint Retrospective Meetings for Upgrading Lessons Learnt and Risk Management Principles
e 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. is 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. e 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. APMbased 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. is means that the team can improve its performance during the succession of sprints, which is called velocity in agile vocabulary.
ere 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? e main advantage of APM principles application is that adjustments can be made on a regular basis.

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 Figure 1). 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. is 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). is 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.
ird, remaining human resistance is twofold and is not directly related to introduction of CST principles into PRM. ere are some company-level issues, like silos, territories, and informal networks.
ese 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.

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 eory and Agile Project Management have been combined into an upgraded Project Risk Management approach. e global aim is to link autonomy in execution and structure in coordination: less execution rules, more coordination rules. e main intermediary result of this combination is that agile principles make CST principles lighter to understand and to apply. e 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 Figure 5). 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, risksactions, actions-actors, and actions-actions).
ird, 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). is 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.
ey 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 Figure 1). 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.

Data Availability
e illustrative example data used to support the findings of this study are available from the corresponding author upon request.

Conflicts of Interest
e author declares that there are no conflicts of interest.