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

Marle, Franck

doi:https://doi.org/10.1155/2020/3739129

Complexity

On this page

Abstract Introduction Conclusions Data Availability Conflicts of Interest References Copyright Related Articles

Research Article | Open Access

Volume 2020 | Article ID 3739129 | https://doi.org/10.1155/2020/3739129

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

Franck Marle¹

Academic Editor: Ning Cai

Received06 Apr 2020

Revised07 Jul 2020

Accepted30 Jul 2020

Published10 Oct 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.

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. 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. 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 (; I = 5) and (; 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 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). 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.

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

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 Theory 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.

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, R_i declares an interdependency with another risk R_j; then, this tool automatically duplicates the information into R_j 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 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. 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 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.

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

5.2.2. Risk Interdependency Assessment

The 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. This is called P(R_j∣R_i), the probability of R_j knowing R_i, 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 (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). 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 (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.

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

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 (Figure 5), 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 R₄₉, R₂₇, R₁₆, and R₁₉) 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 R₁₀, R₁₃, R₃₉, and R₁₂) 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 R₁₂. Finally, red triangles at the bottom of the figure (R₂, R₄₃, R₅₂, and R₅₅) 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.

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 (Figure 6). 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.

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. 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, R₁₀ “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₃ “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₃ is in a yellow cell, R₁₀, 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 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₂₂ “potential risks of claim from Civil Work subcontractor” and R₃ “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 call risk 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 Figure 7, 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).

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 (Figure 8). In the tramway project example, several data are available in the Action Card (Figure 8):(1)Action A₁₂ is assigned to risk R₃₀(2)Actor 1 is the action owner(3)Action cost is 20 (k€ here)(4)The strategy is to avoid risk R₃₀, meaning that probability of R₃₀ is supposed to be reduced to 0(5)Action A₁₂ comes from Individual Criticality Analysis, meaning that this is the Individual Importance of risk R₃₀ that justified the inclusion of A₁₂ in the operational backlog(6)A₁₂ blocks action A₁₈, meaning that the latter needs an output, an information, or a resource that is not available until A₁₂ is finished

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 (Figure 9):(1)The title of the risk (here risk R₁₀)(2)The Risk Owner (actor 4)(3)The risk cluster (if applicable) here R₁₀ 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 (R₁₀ is related to R₂, R₄₇, and R₄₄)(6)The dependencies with actions that have been identified to impact R₁₀ (A₁₈ and A₁₄)

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

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.

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

The 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)

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

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 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. 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 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, 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 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

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

Conflicts of Interest

The author declares that there are no conflicts of interest.

References

PMI, A Guide to the Project Management Body of Knowledge: PMBOK Guide, Project Management Institute, Newtown Square, PA, USA, 5th edition, 2013.
ISO, ISO 31000:2009(E)—Risk Management—Principles and Guidelines, International Organization for Standardization, Geneva, Switzerland, 2009.
F. Marle and L.-A. Vidal, Managing Complex, High-Risk Projects, Springer, Berlin, Germany, 2016.
C. Beste, T. Welo, and N. Olsson, “Influence of innovation, complexity and newness on success in new product development projects: a survey in Norwegian manufacturing industry,” Proceedings of the Design Society: Design Conference, vol. 1, pp. 511–520, 2020.
View at: Publisher Site | Google Scholar
B. G. Tavares, C. E. S. da Silva, and A. D. de Souza, “Risk management analysis in scrum software projects,” International Transactions in Operational Research, vol. 26, no. 5, 2019.
View at: Publisher Site | Google Scholar
J. Mu, G. Peng, and D. L. MacLachlan, “Effect of risk management strategy on NPD performance,” Technovation, vol. 29, no. 3, pp. 170–180, 2009.
View at: Publisher Site | Google Scholar
K. Gericke, Enhancing Project Robustness: A Risk Management Perspective, Technische Universität Berlin, Berlin, Germany, 2011.
M. Miterev, A. Jerbrant, and A. Feldmann, “Exploring the alignment between organization designs and value processes over the program lifecycle,” International Journal of Project Management, vol. 38, no. 2, pp. 112–123, 2020.
View at: Publisher Site | Google Scholar
P. Willumsen, J. Oehmen, V. Stingl, and J. Geraldi, “Value creation through project risk management,” International Journal of Project Management, vol. 37, no. 5, pp. 731–749, 2019.
View at: Publisher Site | Google Scholar
B. Edmonds, “What is complexity?—the philosophy of complexity per se with application to some examples in evolution,” 1995.
View at: Google Scholar
D. Chu, R. Strand, and R. Fjelland, “Theories of complexity,” Complexity, vol. 8, no. 3, pp. 19–30, 2003.
View at: Publisher Site | Google Scholar
D. Braha, A. Minai, and Y. Bar-Yam, Complex Engineered Systems: Science Meets Technology, Springer, Berlin, Germany, 2006.
P. Svejvig and P. Andersen, “Rethinking project management: a structured literature review with a critical look at the brave new world,” International Journal of Project Management, vol. 33, no. 2, pp. 278–290, 2014.
View at: Google Scholar
Q. Yang, T. Lu, T. Yao, and B. Zhang, “The impact of uncertainty and ambiguity related to iteration and overlapping on schedule of product development projects,” International Journal of Project Management, vol. 32, no. 5, pp. 827–837, 2014.
View at: Publisher Site | Google Scholar
T. Brady and A. Davies, “Managing structural and dynamic complexity: a tale of two projects,” Project Management Journal, vol. 45, no. 4, pp. 21–38, 2014.
View at: Publisher Site | Google Scholar
L.-A. Vidal, “Thinking project management in the age of complexity, particular implications on project risk management,” 2009.
View at: Google Scholar
M. F. Mikkelsen, “The complex project complexity—identification of five ideal research types,” Journal of Modern Project Management, vol. 7, no. 4, 2020.
View at: Google Scholar
Y. Zhang, C.-H. Tsai, and P.-C. Liao, “Rethinking risk propagation mechanism in public–private partnership projects: network perspective,” Journal of Infrastructure Systems, vol. 26, no. 2, Article ID 04020011, 2020.
View at: Publisher Site | Google Scholar
A. F. De Toni and E. Pessot, “Investigating organisational learning to master project complexity: an embedded case study,” Journal of Business Research, 2020.
View at: Publisher Site | Google Scholar
A. Maqsoom, M. Hamad, H. Ashraf, M. J. Thaheem, and M. Umer, “Managerial control mechanisms and their influence on project performance: an investigation of the moderating role of complexity risk,” Engineering, Construction and Architectural Management, 2020.
View at: Publisher Site | Google Scholar
M. Jorgensen, “Relationships between project size, agile practices, and successful software development: results and analysis,” IEEE Software, vol. 36, no. 2, pp. 39–43, 2019.
View at: Google Scholar
F. Acebes, J. Pajares, J. M. Galán, and A. López-Paredes, “A new approach for project control under uncertainty. Going back to the basics,” International Journal of Project Management, vol. 32, no. 3, pp. 423–434, 2014.
View at: Publisher Site | Google Scholar
F. Marle and T. Gidel, “Assisting project risk management method selection,” International Journal of Project Management, vol. 6, no. 3, 2015.
View at: Google Scholar
J. A. Keizer, J. I. M. Halman, and M. Song, “From experience : applying the risk diagnosing methodology,” Journal of Product Innovation Management, vol. 19, pp. 213–232, 2002.
View at: Google Scholar
S. Kaplan and S. Vishnepolschi, New Tools for Failure and Risk Analysis, Anticipatory Failure Détermination (AFD) and the Theory of Scenario Structuring, Ideation International Inc., Southfield, MI, USA, 1999.
P. E. D. Love and D. J. Edwards, “Curbing rework in offshore projects: systemic classification of risks with dialogue and narratives,” Structure and Infrastructure Engineering, vol. 9, no. 11, pp. 1118–1135, 2013.
View at: Publisher Site | Google Scholar
E. Maytorena, G. M. Winch, J. Freeman, and T. Kiely, “The influence of experience and information search styles on project risk identification performance,” IEEE Transactions on Engineering Management, vol. 54, no. 2, pp. 315–326, 2007.
View at: Publisher Site | Google Scholar
B. Barghi and S. Shadrokh, “Qualitative and quantitative project risk assessment using a hybrid PMBOK model developed under uncertainty conditions,” Heliyon, Article ID e03097, 2019.
View at: Publisher Site | Google Scholar
S. M. H. Mojtahedi, S. M. Mousavi, and A. Makui, “Project risk identification and assessment simultaneously using multi-attribute group decision making technique,” Safety Science, vol. 48, no. 4, pp. 499–507, 2010.
View at: Publisher Site | Google Scholar
H. Yan, C. Gao, H. Elzarka, K. Mostafa, and W. Tang, “Risk assessment for construction of urban rail transit projects,” Safety Science, vol. 118, pp. 583–594, 2019.
View at: Publisher Site | Google Scholar
MIL-STD-1629, Procedures for Performing FMECA, 1998.
L. M. Khodeir and M. Nabawy, “Identifying key risks in infrastructure projects—case study of Cairo festival city project in Egypt,” Ain Shams Engineering Journal, vol. 10, no. 3, pp. 613–621, 2019.
View at: Publisher Site | Google Scholar
J. H. Lambert, Y. Y. Haimes, D. Li, R. M. Schooff, and V. Tulsiani, “Identification, ranking, and management of risks in a major system acquisition,” Reliability Engineering and System, vol. 72, 2001.
View at: Publisher Site | Google Scholar
R. J. Chapman, “The effectiveness of working group risk identification and assessment techniques,” International Journal of Project Management, vol. 16, no. 6, pp. 333–343, 1998.
View at: Publisher Site | Google Scholar
M. J. Carr, S. L. Konda, I. Monarch, C. Ulrich, and C. Walker, Taxonomy-Based Risk Identification, SEI, Oaks, PA, USA, 1993.
C. Chapman and S. Ward, How to Manage Project Opportunity and Risk: Why Uncertainty Management Can Be a Much Better Approach than Risk Management, John Wiley & Sons Ltd., Chichester, UK, 2011.
R. Smaling and O. De Weck, “Assessing risks and opportunities of technology infusion in system design,” Systems Engineering, vol. 10, no. 1, pp. 1–25, 2006.
View at: Google Scholar
A. S. Chauhan, B. Nepal, G. Soni, and A. P. S. Rathore, “Examining the state of risk management research in new product development process,” Engineering Management Journal, vol. 30, no. 2, pp. 85–97, 2018.
View at: Publisher Site | Google Scholar
A. C. Cagliano, S. Grimaldi, and C. Rafele, “Choosing project risk management techniques. A theoretical framework,” Journal of Risk Research, vol. 18, no. 2, pp. 232–248, 2015.
View at: Publisher Site | Google Scholar
P. de Araujo Lima, M. Crema, and C. Verbano, “Risk management in SMEs: a systematic literature review and future directions,” European Management Journal, vol. 38, no. 1, pp. 78–94, 2020.
View at: Publisher Site | Google Scholar
Y.-S. Chen, H.-M. Chuang, A. K. Sangaiah, C.-K. Lin, and W.-B. Huang, “A study for project risk management using an advanced MCDM-based DEMATEL-ANP approach,” Journal of Ambient Intelligence and Humanized Computing, vol. 10, no. 7, pp. 2669–2681, 2018.
View at: Publisher Site | Google Scholar
G. Di Bona, A. Silvestri, A. Forcina, and A. Petrillo, “Total efficient risk priority number (TERPN): a new method for risk assessment,” Journal of Risk Research, vol. 21, no. 11, pp. 1384–1408, 2017.
View at: Publisher Site | Google Scholar
A. Desroches, “Risque moyen, criticite et gouvernance du risque,” 2009.
View at: Google Scholar
J. P. Monat and S. Doremus, “An alternative to heat map risk matrices for project risk prioritization,” Journal of Modern Project Management, vol. 5, no. 2, pp. 104–112, 2018.
View at: Google Scholar
J. P. Monat and S. Doremus, “An improved alternative to heat map risk matrices for project risk prioritization,” Journal of Modern Project Management, vol. 7, no. 4, 2020.
View at: Google Scholar
Q. Yang, K.-S. Chin, and Y.-L. Li, “A quality function deployment-based framework for the risk management of hazardous material transportation process,” Journal of Loss Prevention in the Process Industries, vol. 52, pp. 81–92, 2018.
View at: Publisher Site | Google Scholar
Y. Zhang and Z.-P. Fan, “An optimization method for selecting project risk response strategies,” International Journal of Project Management, vol. 32, no. 3, pp. 412–422, 2014.
View at: Publisher Site | Google Scholar
J. Wang, W. Lin, and Y.-H. Huang, “A performance-oriented risk management framework for innovative R&D projects,” Technovation, vol. 30, no. 11-12, pp. 601–611, 2010.
View at: Publisher Site | Google Scholar
D. Wu, J. Li, T. Xia, C. Bao, Y. Zhao, and Q. Dai, “A multiobjective optimization method considering process risk correlation for project risk response planning,” Information Sciences, vol. 467, pp. 282–295, 2018.
View at: Publisher Site | Google Scholar
Y. Zhang, F. Zuo, and X. Guan, “Integrating case-based analysis and fuzzy optimization for selecting project risk response actions,” Physica A, vol. 545, 195 pages, 2020.
View at: Publisher Site | Google Scholar
C. Fang, F. Marle, M. Xie, and E. Zio, “An integrated framework for risk response planning under resource constraints in large engineering projects,” IEEE Transactions on Engineering Management, vol. 60, no. 3, 2013.
View at: Publisher Site | Google Scholar
S. Mäkinen, “A strategic framework for business impact analysis and its usage in new product development,” Acta Polytechnica Scandinavica, vol. 2, no. 1, p. 213, 1999.
View at: Google Scholar
A. Hevner, S. March, J. Park, and S. Ram, “Design science research in information systems,” MIS Quarterly, vol. 28, no. 1, 2004.
View at: Google Scholar
L. Pekkinen and K. Aaltonen, “Risk management in project networks: an information processing view,” Technology and Investment, vol. 6, no. 1, pp. 52–62, 2015.
View at: Publisher Site | Google Scholar
K. T. Yeo and Y. Ren, “Risk management for complex product systems (CoPS) projects,” Systems Engineering, vol. 12, no. 4, pp. 275–294, 2008.
View at: Google Scholar
F. Marle, “A structured process to managing complex interactions between project risks,” International Journal of Project Organisation and Management, vol. 6, no. 1-2, pp. 4–32, 2014.
View at: Publisher Site | Google Scholar
C. Fang and F. Marle, “A simulation-based risk network model for decision support in project risk management,” Decision Support System, vol. 52, no. 3, 2012.
View at: Publisher Site | Google Scholar
C. Fang, F. Marle, E. Zio, and J.-C. Bocquet, “Network theory-based analysis of risk interactions in large engineering projects,” Reliability Engineering and System Safety, vol. 106, 2012.
View at: Publisher Site | Google Scholar
P. Elkington and C. Smallman, “Managing project risks : a case study from the utilities sector,” International Journal of Project Management, vol. 20, no. 263, pp. 49–57, 2002.
View at: Publisher Site | Google Scholar
T. Lyons and M. Skitmore, “Project risk management in the Queensland engineering construction industry: a survey,” International Journal of Project Management, vol. 22, no. 1, pp. 51–61, 2004.
View at: Publisher Site | Google Scholar
E. Kutsch and M. Hall, “Intervening conditions on the management of project risk: dealing with uncertainty in information technology projects,” International Journal of Project Management, vol. 23, no. 8, pp. 591–599, 2005.
View at: Publisher Site | Google Scholar
P. Pritchard, The Project Leadership Process in Production Line Projects with Different Types of Complexities, ProQuest Dissertations Publishing, Ann Arbor, MI, USA, 2020.
F. Caron, Managing the Continuum: Certainty, Uncertainty, Unpredictability in Large Engineering Projects, Springer, Milano, Italy, 2013.
K. Beck, “The agile manifesto,” 2001, http://www.agilemanifesto.org.
View at: Google Scholar
D. J. Fernandez and J. D. Fernandez, “Agile project management—agilism versus traditional approaches,” Journal of Computer Information Systems, vol. 49, no. 2, p. 10, 2009.
View at: Google Scholar
S. Bajpai, S. D. Eppinger, and N. R. Joglekar, “The structure of agile development under scaled planning and coordination,” in Proceedings of the 21st International DSM Conference, pp. 23–25, Monterey, CA, USA, September 2019.
View at: Google Scholar
B. Robertson, Holacracy: The New Management System for a Rapidly Changing World, Henry Holt and Company, New York, NY, USA , 2015.
B. Robertson, “Evolving organization,” Integral Leadership Review, vol. 7, no. 3, 2007.
View at: Publisher Site | Google Scholar
G. Charest, La gestion par consentement: une nouvelle facon de partager le pouvoir (Management by Consent: A New Way of Sharing Power), Editions Transcontinental, Montreal, Canada, 1996.
F. Laloux, Reinventing Organizations: Vers des Communautés de Travail Inspirées, Diateino, Paris, France, 2015.
I. Getz and B. M. Carney, Freedom Inc., Crown Business/Random House, 2009.
K. Schwaber, Agile Project Management with Scrum, O’Reilly Media, Sebastopol, CA, USA, 2009.
T. S. Nguyen and S. Mohamed, “Interactive effects of agile response-to-change and project complexity on project performance,” in 10th International Conference on Engineering, Project, and Production Management, pp. 311–320, Springer, Singapore, 2020.
View at: Google Scholar
M. L. Drury-Grogan, K. Conboy, and T. Acton, “Examining decision characteristics & challenges for agile software development,” Journal of Systems and Software, vol. 131, pp. 248–265, 2017.
View at: Publisher Site | Google Scholar
B. G. Tavares, C. E. S. Da Silva, and A. D. De Souza, “Risk management in scrum projects: a bibliometric study,” Journal of Communications Software and Systems, vol. 13, no. 1, pp. 1–8, 2017.
View at: Publisher Site | Google Scholar
M. Hammad and I. Inayat, “Integrating risk management in scrum framework,” in Proceedings of the 2018 International Conference on Frontiers of Information Technology, FIT 2018, Islamabad, Pakistan, December 2018.
View at: Google Scholar
H. Andrat and S. Jaswal, “An alternative approach for risk assessment in scrum,” in Proceedings of the 2015 International Conference on Computing and Network Communications, CoCoNet 2015, Kauai, HI, USA, February 2016.
View at: Google Scholar
P. Leung, K. Ishii, J. Abell, and J. Benson, “Distributed system development risk analysis,” Journal of Mechanical Design, vol. 130, no. 5, pp. 1–9, 2008.
View at: Publisher Site | Google Scholar
D. Dönmez and G. Grote, “Two sides of the same coin—how agile software development teams approach uncertainty as threats and opportunities,” Information and Software Technology, vol. 93, pp. 94–111, 2018.
View at: Publisher Site | Google Scholar
J. Nyjford and M. Kajko Mattsson, “Commonalities in risk management and agile process models,” in Proceedings of the Conference on Software Engineering Advances (ICSEA), French Riviera, France, August 2007.
View at: Google Scholar
C. Nelson, G. Taran, and L. de Lascurain Hinojosa, “Explicit risk management in agile process,” in Lecture Notes in Business Information Processing,Agile Processes in Software Engineering and Extreme Programming, pp. 190–201, Springer, Berlin, Germany, 2008.
View at: Google Scholar
H. Kunreuther, “Risk management strategies for dealing with interdependencies,” in Conference on Network-Based Strategies and Competencies, Philadelphia, CA, USA, November 2007.
View at: Google Scholar
N. Worren, Organisation Design: Re-defining Complex Systems, Pearson, London, UK, 2012.
F. Marle, Modèles d’information et Méthodes Pour Aider à la Prise de Décision en Management de Projets, Ecole Centrale Paris, Châtenay-Malabry, France, 2002.
T. R. Browning, “Applying the design structure matrix to system decomposition and integration problems: a review and new directions,” IEEE Transactions on Engineering Management, vol. 48, no. 3, pp. 292–306, 2001.
View at: Publisher Site | Google Scholar
H. Jaber, F. Marle, L.-A. Vidal, and L. Didiez, “Reciprocal enrichment of two multi-domain matrices to improve accuracy of vehicle development project interdependencies modeling and analysis,” in Proceedings of the 16th International Dependency and Structure Modelling Conference, DSM 2014, Paris, France, July 2014.
View at: Google Scholar
S.-J. Chen and L. Lin, “Decomposition of interdependent task group for concurrent engineering,” Computers & Industrial Engineering, vol. 44, no. 4, pp. 633–650, 2003.
View at: Publisher Site | Google Scholar
V. Valencia, “Network Interdependency Modeling for Risk Assessment on Built Infrastructure Systems,” Air Force Institute of Technology, Bengaluru, India, 2013.
View at: Google Scholar
L.-A. Vidal, F. Marle, and J.-C. Bocquet, “Measuring project complexity using the analytic hierarchy process,” International Journal of Project Management, vol. 29, no. 6, pp. 718–727, 2011.
View at: Publisher Site | Google Scholar
K. Sinha and O. De Weck, “Structural and topological analysis of “real-world” product structures,” in Proceedings of the International Design Structure Matrix Conference, Greenville, SC, USA, 2009.
View at: Google Scholar
D. Braha and Y. Bar-Yam, “Topology of large-scale engineering problem-solving networks,” Physical Review E, vol. 69, no. 1, 2004.
View at: Publisher Site | Google Scholar
S. S. Perera, M. G. H. Bell, M. Piraveenan, D. Kasthurirathna, and M. Parhi, “Topological structure of manufacturing industry supply chain networks,” Complexity, vol. 2018, Article ID 3924361, 23 pages, 2018.
View at: Publisher Site | Google Scholar
C. Ongkowijoyo and H. Doloi, “Determining critical infrastructure risks using social network analysis,” International Journal of Disaster Resilience in the Built Environment, vol. 8, no. 1, pp. 5–26, 2017.
View at: Publisher Site | Google Scholar
D. C. Wynn, N. H. M. Caldwell, and P. John Clarkson, “Predicting change propagation in complex design workflows,” Journal of Mechanical Design, vol. 136, no. 8, Article ID 081009, 2014.
View at: Publisher Site | Google Scholar
M. C. Pasqual and O. L. De Weck, “Multilayer network model for analysis and management of change propagation,” Research in Engineering Design, vol. 23, no. 4, pp. 305–328, 2012.
View at: Publisher Site | Google Scholar
H. Jaber, F. Marle, L.-A. Vidal, and L. Didiez, “Criticality and propagation analysis of impacts between project deliverables,” Research in Engineering Design, vol. 29, no. 1, pp. 87–106, 2017.
View at: Publisher Site | Google Scholar
F. Marle and L.-A. Vidal, “Potential applications of DSM principles in project risk management,” in Proceedings of the 10th International DSM Conference, Stockholm, Sweden, November 2008.
View at: Google Scholar
S. Kherbachi, N. Benkhider, and N. Keddari, “Application of pagerank in virtual organization architecture,” Research Journal of Computer and Information Technology Sciences, vol. 1, no. 1, pp. 1–14, 2020.
View at: Google Scholar
K. Schwaber and J. Sutherland, The Scrum Guide, scrum.org, 2013.
K. Rubin, Essential Scrum: A Practical Guide to the Most Popular Agile Process, Addison-Wesley, Boston, MA, USA, 2012.
V. Stray, N. B. Moe, and D. I. K. Sjoberg, “Daily stand-up meetings: start breaking the rules,” IEEE Software, vol. 37, no. 3, pp. 70–77, 2020.
View at: Publisher Site | Google Scholar

Copyright

Copyright © 2020 Franck Marle. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

PDF Download Citation

Download other formats

Order printed copies

Views

6091

Downloads

2734

Citations