Ludovic-Alexandre Vidal
email: ludovic-alexandre.vidal@ecp.fr

Franck Marle
email: franck.marle@ecp.fr

Understanding project complexity Implications on project management

Keywords: Project management, complexity, uncertainty, risk, modelling, systems analysis

Purpose

Better identify, define and model complexity within the field of project management in order to manage better under conditions of complexity (and manage better complexity-induced risks).

Design / Methodology / Approach

A large literature review enlightens the lack of consensus on project complexity and thus provides a broad view and a critical analysis of the underlying concepts. A project complexity framework and definition are then proposed. After underlining the stakes of project complexity in accordance with these proposals, a project complexity model is then built notably thanks to systems analysis.

Findings

Proposal of standard project complexity framework and definition. Proposal of a synthesis of the relationships between the concepts of project uncertainty and project complexity. Proposal of a project complexity model (and validation thanks to industrial application).

Research limitations / implications

The literature review and project complexity framework tries to be exhaustive even though it is likely to be completed. The final version of the model is still to be computed and tested.

Practical implications

Avoid confusion when defining and managing a complex project, particularly between project team members (and as a consequence improve communication and information sharing). Better assess the propagation of a change within the project.

Originality / Value

The paper proposes an original framework and definition of project complexity. The complexity model permits the navigation from any element of the project to any other (when detail is needed) and is as a consequence original and complementary with traditional project management models and tools.

Introduction

A project is a temporary and unique endeavour undertaken to deliver a result. This result is always a change in the organization, whatever it is in its processes, performance, products or services. This transformation consists then in a gap between a start and a final state. Time and resources are consumed to produce results, which may be deliverables and/or performance improvement and/or resource improvement (skills, knowledge). Each project is unique because there is always at least one of the following parameters that changes: targets, resources and environment. As projects became more and more present into organizations, and as they had bigger and bigger amounts at stake, it became impossible to let them live without specific and rigorous methodology. As a consequence, project management was created as a formalized and structured methodology. It is usually admitted than modern project management appeared during World War II and was initially dedicated to big military and construction projects.

Project management has then grown up and spread around the world to become what it is today, that is to say a set of theories, principles, methodologies and practices, sometimes included in standard body of knowledge as PMI (PMI, 2004) and IPMA (IPMA, 2006 a). The current vision tends to rely upon the notions of planning and control to propose models and prescriptions as ways to increase the ability of humans to control complex worlds (Stacey, 2001), (Wood, 2002). It emphasises the role of project actors regarding the issues of time, cost and scope (Cicmil and al., 2006).

For all practical purposes, lots of studies have been done, based on statistical calculations or surveys. Their conclusion is that current methods have shown their limits, since they cannot face anymore the stakes of ever growing project complexity. Limits and lacks have indeed been detected in research as well as in industry about the project predictability, since usual parameters (time, cost and quality) are clearly not sufficient to describe properly the complete situation at a given time (Meijer, 2002), (Jaafari, 2003), (Williams, 1999). This articles aims then at describing the concept of project complexity thanks to a large literature review in order to understand what the underlying notions behind this concept are. It notably focuses on project complexity factors and builds an innovative and exhaustive project complexity framework that could be a reference for any project which has to face the complexity stakes. Finally, this article aims at proposing a definition of project complexity before having a look at the impacts of complexity on project management and studying how it can be modelled and analysed. It must be noted that the article discusses at several moments the links between the two concepts of complexity and uncertainty in order to make a clear distinction between them and therefore avoid confusion. Perspectives for future research work in this field are finally given.

Former research works on complexity and project complexity

Prerequisite for this section: the project system According to systems analysis (Penalva, 1997), (Le Moigne, 1990), (Boulding, 1956), (Marle, 2002), (Vidal and al., 2007) a system is an object, which, in a given environment, aims at reaching some objectives (teleological aspect) by doing an activity (functional aspect) while its internal structure (ontological aspect) evolves through time (genetic aspect) without losing its own identity. Projects can thus be considered as systems. Indeed, a project exists within a specific environment and aims at reaching objectives given this context (teleological aspect). A project has to accomplish a network of activities using some methods and methodologies (functional aspect). A project has an internal structure composed of resources, deliverables, tools, workers, etc… (ontological aspect). Finally, a project evolves through time, via resource consumption, product delivery, members' changes and gain of experience, without losing its own identity (genetic aspect). As a consequence, in the following of this article, we consider projects as systems and thus study the field of complex systems to deal with project complexity.

Complexity and project complexity

Complexity is everywhere and is continuously growing, with an increasing pace. Research works on the concept of complexity have been conducted for years and have produced some interesting results and notions. There are historically two main scientific approaches of complexity (Schlindwein and al., 2005). The one, usually known as the field of descriptive complexity, considers complexity as an intrinsic property of a system, a vision which incited researchers to try to quantify or measure complexity. An example of this vision is the work of Baccarini (Baccarini, 1996). He considers project complexity through the concepts of technological complexity and organisational complexity. He regards them as the core components of project complexity which he tries to describe exhaustively. The other one, usually known as the field of perceived complexity, considers complexity as subjective, since the complexity of a system is improperly understood through the perception of an observer.

Both approaches can apply to project complexity and project management complexity. For all practical purposes, a project manager deals with perceived complexity as he cannot understand and deal with the whole reality and complexity of the project. As a consequence, this article aims at creating a link between those two traditional visions of complexity. Knowing that one tries to cope with perceived complexity, this research aims at bridging the gap between perceived complexity and real complexity by defining, describing and modelling better real project complexity. This new frame of reference would enable anyone who shares this representation to perceive more properly the project reality.

The difficulty is that there is actually a lack of consensus on what project complexity really is. As Sinha and al. (Sinha and al., 2001) underline it, "there is no single concept of complexity that can adequately capture our intuitive notion of what the word ought to mean". Complexity can be understood in different ways not only in different fields but has also different connotations within the same field (Morel and al., 1999). However, Edmonds (Edmonds, 1999) proposes an overview of the concept of complexity within different fields and finally tries to give a generic definition of what complexity is: "Complexity is that property of a model which makes it difficult to formulate its overall behaviour in a given language, even when given reasonably complete information about its atomic components and their inter-relations". This definition, which is quite appropriate to encompass all the aspects of project complexity, emphasises that complexity is generally related to the way the project system is modelled. To some extent, the model is the first layer of the project perception, the second layer being the perception when understanding the project model.

According to Marle (Marle, 2002), who notably follows the concepts of Genelot (Genelot, 2001), it must be noted that complexity is the property of a system that causes on one hand the emergence of new properties that none of the elements of the system owns, and on the other hand the apparition of phenomena that could not be predicted thanks to the sole knowing, even complete, of the behaviour and interactions of the elements of the system. Complexity can thus have both a negative aspect (in terms of difficulty to be understood or contolled) and a positive influence on the project system (thanks to the emergence of opportunities).

As a whole, whatever the vision of complexity one has, the project system can be considered as a complex system. However, some work is to be done to clarify the notion of project complexity in order to cope with it more efficiently. Due to the lack of consensus between the different visions and definitions of complexity, even though the manipulated concepts are sometimes very near, many research works tried to define and identify some key factors and drivers of project complexity, but there is no standardized and commonly-agreed list of project complexity drivers in the literature either. The next section aims at addressing the notion of project complexity in terms of its characteristics and factors in order to build a project complexity framework that could be a reference for any project.

Project complexity factors and characteristics

After a literature review on project management and project complexity (Baccarini, 1996), (Sinha and al., 2001), (Marle, 2002), (AFNOR), (IPMA, 2006 b), (Laurikkala andal., 2001), (Aissa, 2004) etc., we do argue that project complexity can be characterized through some factors that can be classified into four families (see Figure 1). All are necessary but non-sufficient conditions for project complexity. The first family encompasses project size factors. The second one gathers factors of project variety. The third one gathers those that are relative to the interdependencies and interrelations within the project system. Finally, the fourth one deals with project complexity context-dependence. In this section, we give a few words about them and then build a new project complexity framework according to this classification.

Figure 1. Drivers of project complexity

The size of the project system

The size of the project system appears to be a necessary condition for project complexity. For instance, a recent paper states that the organisational system should be over a minimum critical size to be considered as a complex system (Corbett and al., 2002). As a consequence, the size of the project system is a project complexity factor and identifying the parameters that characterize the size of the project system gives a first list of drivers of project complexity when one focuses on what project size means.

The variety of the project system

The project system variety appears to drive project complexity too. As mentioned by Sherwood and Anderson (Sherwood and al., 2005), "diversity relates closely to the number of emergent properties" and is a necessary condition for project complexity. As underlined by Corbett and al. (Corbett and al., 2002), "the one thing that comes through loud and clear is that complexity is tied up with variety, be it in the world of biology, physics or manufacturing. Moreover, it has something to do with how all of this variety interacts". This aspect of project complexity in terms of interactions and interdependencies within the project system exactly clings to the third family of project complexity factors which is described in the following paragraph.

Interdependencies within the project system

As underlined by several authors, interdependencies are likely to be the greatest drivers of project complexity. Rodrigues and al. (Rodrigues and al., 1996) explain that "experience suggests that the interrelationships between the project's components are more complex than is suggested by the traditional work breakdown structure of project network", suggesting that traditional project management tools cannot be sufficient to catch the reality of interdependence. This seems all the more problematic since "there is a complete interdependence between the components of the complexity: each element will depend and influence on the others" (Calinescu and al., 1998).

Context-dependence

Chu and al. (Chu and al., 2003) underline that contextuality is an essential feature of complexity, considering it as a common denominator of any complex system. Project complexity context-dependence is also underlined by Koivu and al. (Koivu and al., 2004) who notably insist on the fact that "the context and practices that apply to one project are not directly transferable to other projects with different institutional and cultural configurations, which have to be taken into account in the processes of project management and leadership". As a consequence, project complexity cannot be neither analysed nor managed without considering the implications of the project context on it.

Conclusion : building a project complexity framework.

The broad literature review we carried out enabled us to build a project complexity framework that aims at being a reference for any project manager to identify and characterize some aspects of its project complexity, so that he can understand more efficiently the stakes of its project complexity management. Even though we had the ambition to be exhaustive, some others project complexity factors might be added to this framework. In addition to the classification of these factors according to the four families we identified, we use Baccarini's wellestablished dichotomy considering that project complexity is composed of technological complexity and organisational complexity.

Hereinafter, on Table I, the completed project complexity framework we have built thanks to this review is exposed. Even though the factors belonging to the family of interdependencies within the project system are hardly more numerous that the others, this class appears to be the most important for project complexity and dayto-day project management (Marle, 2002). Interactions management is likely to be both one of the causes of greatest value creation during the project and one of the riskiest parts of the project. Finally, it has to be noticed that approximately 70% of the identified complexity factors are related to organizational aspect, not technical. propose a definition of project complexity. We state that "project complexity is the property of a project which makes it difficult to understand, foresee and keep under control its overall behaviour, even when given reasonably complete information about the project system. Its drivers are factors related to project size, project variety, project interdependence and project context."

Every aspect of systemics is part of the overall behaviour of the project system, which means that, according to this definition, project complexity is the property which makes it difficult to understand, foresee and keep under control any of these aspects. The reader is to keep in mind this definition until the end of this article as the next section aims at exploring the stakes of project complexity.

The stakes of project complexity

Understanding the consequences of project complexity

This section aims at describing some of the consequences of project complexity in order to understand the stakes of project complexity management and to characterize how it can be helpful to assist global project management.

The links between project complexity, project risks, project uncertainty and project performance are still unclear in the academic world as well as in the industrial one. For instance, Parsons-Hann and Liu state that "it is clear that requirements complexity contributes to project failure in organisations, what is not apparent is to what degree this statement holds true". (Parsons-Hann and al., 2005) Even if the relation between risks and complexity has to be clarified, complexity appears to be one of the main reasons of the unpredictability of projects, particularly in terms of problems and failures. As mentioned in the project complexity framework we have built, there is a high number and great diversity of objects to manage, with a high number and great diversity of parameters that characterize them. The amount and diversity of these interactions are so huge that project objects rapidly become unmanageable thanks to the sole use of classical tools and methods of project management. Both the complexity of the evolving environment and the internal complexity of the project justify the need for a new approach that would assist the existing ones.

The global issue of project complexity management is then for a project manager to know how to seize the opportunities emerging from complexity and to know how to avoid or at least diminish the negative effects of complexity. That is why we now focus on the main consequences of project complexity.

Uncertainty as a consequence of project complexity

Uncertainty appears as one of the possibly negative consequences of project complexity. This paragraph illustrates how project complexity can be a source of uncertainty, thus making a distinction between these two concepts as some research works argued for it before (Pich and al., 2007), (Little, 2005). In order to follow this paragraph more easily, the reader should refer to the drawn synthesis on Figure 2.

Figure 2. Project complexity as a source of project uncertainty

Let a project manager analyse a project system at a given time T in order to plan his decisions and actions for the next period to reach a state at time T+1. The project system can be described by its real state at time T, a state the real complexity of which can also be considered at time T. When analysing and monitoring the project system at time T, the project manager first perceives the real state at time T, introducing a difference (and thus a source of uncertainty) between the real project state at time T and the perceived project state at time T (∆ 1 (T)).

This difference has two principal causes. On one hand, the project manager has its own culture and references, and thus, his perception of the project system alters reality. On the other hand, real project complexity implies that the project system cannot in essence be completely understood: by definition, there is always an irreducible residual source of uncertainty caused by complexity (mainly due to the high number and variety of elements and interactions that cannot be completely neither identified nor understood) when trying to identify the project system state. For the same reasons, there is a difference (and thus another source of uncertainty ∆ 2 (T)) between perceived project complexity at time T and real project complexity at time T.

This question of perception is approached by Jaafari (Jaafari, 2003) and appears to be a crucial issue for project complexity. Jaafari insists on the fact that individuals, depending on their mental models and representations, perceive the outside reality in their own way. As a consequence, project complexity is dealt with through a filter, which is the individual perception of the project system and environment (based on one's representations). In other terms, the difficulty is that the gaps ∆ 1 (T) and ∆ 2 (T) are different for any project team member as anyone has its own perception of reality. The leadership and adaptability of the project manager is thus crucial in order to try to share a common reference and perception of reality within the project team.

Let us now have an overall look at the global process of project management. The project manager analyses the state of the project at a given time T and considers the difference δ between this state at time T and the state he planned for the next period at time T+1. The project manager then makes decisions under the constraints of project context and perceived complexity and does the corresponding actions to influence the project evolution in order to reach the planned state at time T+1. This process is also altered by complexity-driven uncertainties.

First, decisions can be directly altered by real project complexity. For instance, when transmitting some information about a decision, information can be altered because of cultural variety, staff diversity and staff interdependences. As a consequence, when turning this decision into an action (at the end of the information transmission process), the real action can be different from the action the project manager wanted. Moreover, real complexity has an influence on the impact of the decisions made and the subsequent actions done: the project manager deals with perceived (and not real) project complexity when making its decisions and moreover, real project complexity entails the project manager's inability to forecast efficiently both the impact of its decisions and the project evolution. As a whole, real project complexity is one of the causes of the difference between the planned state at time T+1 and the real state at time T+1, introducing another difference ∆ 3 (T).

Finally, project complexity is also a source of uncertainty in terms of propagation. Indeed, let an uncertain parameter P be in the project system, meaning that the value of P is known under conditions of uncertainty P  δ P .(confidence interval). P can be for instance the duration of a task, the cost of a deliverable, or any dimension of any object of the project system. Since the project system is complex, it includes interdependencies and interconnectivities between its elements (tasks, resources,…). As a consequence, the corresponding uncertainty δ P on a parameter P can spread through the entire system, as any element in relation with parameter P faces uncertainty and transmits to all its neighbours in the same manner.

Uncertainty thus propagates through the entire project system of the complex nature of the project in terms of interaction. Uncertainty propagation is all the more complex to manage since a project, as any complex system, has a high number of various elements and interactions, meaning for example that uncertainty on the duration of a task i can be transmitted in terms of uncertainty on the duration of a task j, which can be transmitted in terms of uncertainty on the cost of a deliverable D, which can then be transmitted in terms of uncertainty on the quality of the global project outcome… In other terms, uncertainty propagation in the project system is even more complex since the project manager has to manage the change of the nature of uncertainty at each stage it is transmitted within the system.

Complexity-driven uncertainties are as a whole a major source of non-decidability and unpredictability for the project system, which is part of the core characteristic of our definition of project complexity (property of a project which confers the inability to understand, foresee and keep under control the project's overall behaviour).

As a consequence, complexity-driven uncertainties are a major source of risks for the project. That is why the next section gives a rough-shape introduction about the more general concept of complexity-induced risks.

Facing complexity-induced risks

First, we remind the reader that, because of the property of emergence, complexity can be a source of risks as well as a source of opportunities. The aspect of opportunity seizing is not dealt with in this article but the reader should keep in mind that complexity is not only a cause of problems. In other terms, no project manager should struggle for complexity reduction: the stake is to properly manage project complexity in order to avoid the negative aspects of it and seize at the same time the opportunities that it creates. For instance, when staffing the project, one should keep in mind aspects of complexity such as staff quantity (avoiding oversize,…) or staff diversity. Millhiser and Solow indeed explain for instance that an optimal level of interaction can be reached in order to make the best compromise between opportunity emergence and complexity induced risks (Millhiser and al., 2007). The concept of complexity induced risks is to be studied. We argue that two main classes of complexity induced risks can occur during a project.

The first class of them gathers all the risks which are directly induced by project complexity. The project complexity framework we have defined is a first basis to identify them. Even though this article does not deal with the elaboration of a methodology that would be used to identify these risks, the general idea of it is to focus on the complexity aspects that have been underlined (corresponding procedures are still to be defined). By paying attention to the key aspects of complexity that can be risky (for instance, some interfaces within the project system), the identification of this first class of complexity induced risks will enable one to complete the risk lists which are usually done thanks to traditional risk analysis methodologies. In the end, one will be able to identify properly a class of risks that was often incompletely identified or even unidentified before.

The second class gathers all the risks which are indirectly induced by project complexity because of the propagation phenomena within the project complex system as mentioned in section 3. In other terms, once an exhaustive project risk list is made, there is still some work to be done to identify and assess the risk of a propagation of one of this identified risk within the project system (as well as the underlying risk of positive feedback and amplification through the system). As Heylighen and al. (Heylighen and al., 2006) underline it, "as technological and economic advances make production, transport and communication ever more efficient, we interact with ever more people, organizations, systems and objects". In the case of project management, the main consequence is that any change in any component in the project system may thus affect any other component of the project system in an unpredictable way because of change propagation. The two last points besides constitute the body of ongoing publications.

In order to illustrate this issue of complexity driven risks, we now consider an example, the case of an IT development project within the pharmaceutical industry. The main developer (who was temporarily engaged in the project) moved to Germany when development was finished, which broke both organisational (communication, knowledge,…) and technical (IT development tools,…) interfaces within the project. For instance, knowledge and competence loss because of this interface break is an example of complexity directly induced risk. Furthermore, later on, when trying to implement the software that had been developed, it entailed the recourse to an IT firm which had to step back on the software development without any expertise on the subject, which implied complementary work, which implied complementary costs and delays. This illustrates the phenomenon of complexity indirectly induced risks as software development and implementation were connected, etc… For all practical purposes, the point is that the project complexity framework is not sufficient to identify efficiently complexity induced risks (especially to identify complexity indirectly induced risks) and to quantify them. Notably, there is a crucial need for efficient complexity modelling in order to identify and assess those risks throughout the model. For instance , as Austin and al. (Austin and al., 2002) mention it in the case of design projects, "to achieve anything more than a superficial understanding of the building design process, the complexities of the design activity have to be identified and represented in an appropriate manner", that is to say thanks to an appropriate approach for modelling. That is why we tackle this issue in the following section.

Complexity modelling as an aid for project and risk management

Objectives of a project complexity model

As mentioned before, anyone deals with real complexity with the filter of perceived complexity. Our ambition is to elaborate a complexity model that can avoid confusion when dealing with project complexity (partially thanks to the project complexity framework we have developed). This model is to encompass all the aspects of project complexity, that is to say project size, project variety, project interactions and elements of context. This model is notably to be used to take up the challenges of complexity and particularly to identify, assess, prevent and/or cure complexity induced risks (of the two classes we defined). Procedures of complexity induced risk management are thus to be elaborated when the final model is built. This section describes the requirements of such a model and describes the model that has been developed thanks to our research works.

Requirements of a good project complexity model

This paragraph aims at defining the requirements of a good project complexity models: a short synthesis of complex models requirements is to be found at the end of this paragraph in Table II. As underlined by Eppinger and al., "good representations make the important things explicit, expose natural constraints to facilitate computation, are complete, are concise, are transparent to its users and suppress detail when it is not required".

( Eppinger and al., 1992) Using this statement as a basis to elaborate an innovative project complexity model helps us to correctly define the scope of this model.

First, the model must make the important aspects of the project system explicit. When referring to the project complexity framework we have built, this means that the model is to explicit all the important elements of the system and their variety, all the important interactions within it and all the important context elements (completeness). On the contrary, everything that does not belong to one of these categories must not be mentioned in the model so that its users feel that the model is strictly related to project complexity (validity and transparency). It must be noted that, as we consider any project as a system, the model is to encompass the four poles of systems analysis.

Moreover, in order to be understood and used easily, the model must suppress unnecessary detail. Indeed, Laurikkala and al. (Laurikkala and al., 2001) argue that modelling at different levels enables one to reduce perceived complexity for all practical purposes since unnecessary guesswork can be considerably reduced. In other terms, a good complexity model should give the possibility for its users to focus more or less on some aspects of the system (suppression of unnecessary detail). The action of modelling is in essence a way to reduce perceived complexity in order to understand it better. Added value

Attributes

The ALOE model seems to meet all the requirements we listed to build a good project complexity model. It is complete, as it permits to describe any characteristic of project complexity. Size and variety are mainly described thanks to objects and attributes. Interdependence is mainly described thanks to links and evolving elements of context are for their part mainly described thanks to events and their impact on the evolution of the system. It also encompasses any aspect of systemics (teleological, ontological, functional, genetic). Unnecessary details can be easily suppressed since the user chooses what elements he decides to focus on in the model. Intuitiveness and understanding are finally facilitated thanks to the possibility to navigate from one object to all its neighbours in order to follow easily the propagation of a change caused by an event within the whole system, which cannot be done by the sole human abstraction and understanding of the system. Finally, even though the ALOE model is still to be computed and tested on different projects in order to validate its utilisation and reliability, the industrial tests and applications of the 3*7 model make us confident in the computability and pertinence of the ALOE model.

Research perspectives on the ALOE model

As mentioned hereinbefore, the ALOE model is still to be computed. Moreover, procedures are still to be defined to permit the practical use of the model in order to detect, prevent and/or cure complexity-induced risks (first class and second class). In order to define those procedures, we first aim at understanding better the two classes of complexity induced risks (that are too often neglected in project risk management with the traditional risk analysis and risk response techniques). We are notably presently working on the identification of complexity directly induced risks thanks to the conjoint use of our project complexity framework and of the ALOE model.

This link between project complexity and risks is to be made thanks to the concept of project vulnerability we are developing. In the end, we hope that the ALOE model will be an innovative tool to assist decision-making when managing complex projects.

Conclusion and final perspectives

After reviewing the literature on complexity and project complexity, this paper tried to give a better vision of the concept of project complexity, notably thanks to the elaboration of a project complexity standardised framework.

This led us to the proposition of a definition of project complexity, the stakes of which were discussed. This whole clarification was helpful to model the project systems and its complexity aspects thanks to a refined interactions model named ALOE that can assist project complexity understanding and management.

Some work is still to be done. First, the ALOE model has to be computed and tested to be finally validated.

Furthermore, research works on the formalisation of complexity induced risks are presently being carried out.

This complexity-driven approach of project management seems to be a promising approach to assist project management in both academic and industrial environment. As a whole, this approach may lead to the elaboration of complexity-based criteria that could help project scenario selection in the case of project management or that could help project selection in the case of multi-project management.

Table I . Project complexity framework : classification of project complexity factors Project System Size Project System Variety Interdependencies within the project system Elements of context Organisational complexity

 I This state of the art being made, this framework being elaborated and the concepts being discussed, we now

	Proposing a definition of project complexity
			Duration of the		Diversity of staff		Availability of people,		Competition
			project		(experience, social		material and of any		Cultural
			Largeness of		span …).		resources due to sharing		configuration and
			capital investment		Geographic		Combined transportation		variety
			Number of		location of the		Dependencies between		Environment
			activities		stakeholders (and		schedules		complexity
			Number of		their mutual		Dependencies with the		(networked
			companies /		disaffection)		environment		environment)
			projects sharing		Variety of financial		Dynamic and evolving		Institutional
			their resources		resources		team structure		configuration
			Number of		Variety of		Interconnectivity and		Local laws and
			decisions to be		hierarchical levels		feedback loops in the task		regulations
			made		within the		and project networks		New laws and
			Number of		organisation		Interdependence between		regulations
			deliverables		Variety of		actors		Organisational
			Number of		information		Interdependence between		degree of innovation
			departments		systems to be		sites, departments and
			involved		combined		companies
			Number of		Variety of		Interdependence of
			hierarchical levels		organisational		information systems
			Number of		interdependencies		Interdependence of
			information		Variety of		objectives
			systems Number of		organisational skills needed		Level of interrelations between phases
		  	investors Number of objectives Number of stakeholders Number of structures / groups / teams to be coordinated	  	Variety of project management methods and tools applied Variety of the interests of the stakeholders Variety of the stakeholders' status	    	Number of interfaces in the project organization Processes interdependence Relations with permanent organizations Stakeholders interrelations Team cooperation and communication
			Staff quantity
	Technological complexity		Number and quantity of resources		Variety of resources to be manipulated		Interdependence between the components of the product	 	Competition Cultural configuration and
			Largeness of		Variety of the		Resource and raw material		variety
			scope (number of		product		interdependencies		Demand of
			components,		components		Specifications		creativity
			etc…)		Variety of		interdependence		Environment
					technological		Technological processes		complexity
					dependencies		dependencies		(networked
					Variety of				environment)
					technological skills				Institutional
					needed				configuration
					Variety of the				Local laws and
					technologies used				regulations
					during the project				New laws and
									regulations
									Scope for
									development
									Significance on
									public agenda
									Technological
									degree of innovation

Acknowledgements

We would like to thank the project complexity working group of the Industrial Engineering Laboratory of Ecole Centrale Paris for the meetings that have helped us to clarify the concept of project complexity.

are not complex enough, they are not enough close to reality to give good results even if used properly. On the contrary, when they are too complex, the human ability to deal with complexity is an impassable difficulty and those models cannot be used efficiently by project managers or project team members. For instance, in the case of decomposition, an empirical rule consists in saying that a human brain can analyse until seven children per object within a maximum range of three levels of decomposition. Keeping all these requirements in mind, we have developed an interactions model that enables one to understand, analyse and manage better every aspect of project complexity that is present in the framework we have built.

Table II. Project complexity models requirements

Complexity theoretical requirements

User requirements Size of the project system

Validity and reliability of the model Variety of the project system Intuitiveness and understandability of the model Interactions and interdependencies within the system

Suppress unnecessary detail

Context and environment dependency of the project system

Completion and concision of the model

Uncertainties and change propagation as consequences of complexity

Computability of the model

Proposition of a complexity model: the ALOE model

A first interactions model (named 3*7), notably built thanks to systemics, was elaborated on by Marle (Marle, 2002) and tested in partnership with PSA Peugeot-Citroën. The model gives the possibility for its users to describe the project system by introducing seven kinds of objects which are characterized by seven kinds of attributes (referring to the size of the project system and the variety of its elements). These elements can be interconnected thanks to the use of seven kinds of links (corresponding to the interdependence within the project system).

When there was sometimes some confusion and lack of agreement on the definition of all the elements that were involved in a project, the 3*7 model gives a general framework and a standardised structure that permits consensus and reality perception sharing within the project team. The model is compatible with other models and tools (WBS, Gantt charts,…) that are global models of a project focusing on one of its dimension (hierarchy, time,…). Its specificity is then to give a better vision at a local level of all the interactions that exist in the environment of any object. Indeed, the 3*7 model makes available all the information about the properties, attributes and interconnected elements of an element of the project system, whatever the nature of the element and the nature of the project are. As a consequence, thanks to this model, one can navigate from an element A of the project system to a neighbour B (connected element), the properties, attributes and internal environment of which are also described thanks to the model.

The 3*7 model proved to be helpful and the industrial added value on the projects was notably to visualise some formerly unformulated information thanks to the identification of the interactions between objects (and therefore of the interrelations between people). For all practical purposes, this permitted notably greater information sharing between project team members (and as a consequence less information loss or alteration). However, we thought that the model could be improved as it did not permit to describe and consider efficiently the project context. In particular, the model structure was not evolutionary enough to reflect the complex dynamics of the project system.

That is why recent research works have leaded us to the elaboration of a complexity model, named ALOE (Attributes, Links, Objects and Events). Some objects, links and attributes definitions have been refined but the greatest difference between the ALOE model and the 3*7 model is the introduction of a new category of elements (events), as shown on Table III. It must be noted that events can be either potential (in which case they are in essence risks) or on the contrary, they can have already occurred. Examples of events can be internal and external decisions, apparition of a new constraint,… Events can have a positive or a negative influence, not only on objects of the system by changing their attributes or by the creation/destruction of new/past objects, but also on links (and their corresponding operators). We finally leave the opportunity for the user to add new events in the system (that spontaneously appear as a consequence of emergence). Organization,9(1),


Ludovic-Alexandre Vidal

Franck Marle

A systems thinking approach for project vulnerability management

Keywords: System, Project, Risk, Vulnerability, Complexity. Classification

Purpose

This papers aims at developing the concept of project vulnerability in order to focus on the weaknesses of a project system, instead of focusing on risk evaluation only. We then aim at concentrating on a systems thinking based view to highlight the potentially endangered elements of a project, including its outcomes.

Design/methodology/approach

• A broad state of the art in many scientific domains.

• A definition of project vulnerability.

• A description of a project vulnerability management process, including identification, analysis and response plan.

• A test on an industrial case study

Findings

Our project vulnerability management process permits to concentrate directly on the existing weaknesses of a project system which may create potential damages regarding the project values creation. By focusing on this system, response plans may be more adapted to the existing lacks of the project.

Research limitations/implications

Some aspects of the vulnerability definition should be refined, like the concepts of susceptibility or cruciality. Other promising works may focus on the evaluation of the nonresistance and resilience, notably thanks to the introduction of interdependences which exist in complex projects.

Practical implications

A case study was done on a decision support system (called FabACT) developed at Hôpital Européen Georges Pompidou Pharmacy department. The aim of this project was to achieve a better balance between the workload and the efficiency of the compounding unit.

Originality/value

This article presents an innovative way to analyse a project's vulnerability by focusing on its existing weaknesses using a systems thinking-based approach.

Introduction

As recent works or communications state it [START_REF] Zhang | A redefinition of the project risk process: Using vulnerability to open up the event-consequence link[END_REF], the concept of vulnerability appears to be promising for efficient risk management, notably within the context of project management. Indeed, it enables to have a more systems-oriented vision than the traditional cindynics approach. This one focuses on the evaluation of risks, instead of focusing on the weaknesses of a system facing these risks. Following a systemic approach when coping with project risk management permits to reduce ambiguity by increasing the awareness of the project system. We then aim at:

• Concentrating on a systems-thinking based view in order to highlight the potentially endangered processes and elements of the project system, including its outcomes.

• Focusing therefore on these elements in order to facilitate the identification and analysis of potential negative events and damages on the system. This paper aims at addressing the concept of project vulnerability by:

• Carrying out a broad state of the art in many scientific domains, in order to understand the concept of vulnerability and to implement it in the context of project management.

• Defining project vulnerability and its characteristics.

• Describing the steps of a project vulnerability management process in order to permit the industrial application of the concept of vulnerability in projects.

• Permitting the identification and analysis of project vulnerabilities thanks to a systems thinking approach focusing on the potential degradation of the project values creation processes.

• Testing the whole approach on a case study.

Background

Etymologically, being vulnerable means either being "capable of being physically or emotionally injured, wounded or hurt", either being "open to temptation, persuasion, censure, etc.", or being "liable or exposed to disease, disaster, etc.". Even though the words vulnerable or invulnerable are thus commonly used in everyday life, little insight has been given to the concept of vulnerability. This paragraph aims at drawing a state of the art on the concept of vulnerability before applying it to project management.

Quantitative analysis of recent publications in the field of vulnerability and in the web of science database

As an illustration of the interest of the present research community for the notion of vulnerability in different scientific fields, we carried out a review and classification of the up to 2007 Web of Science publications which mentioned the world vulnerability in their title. 534 such publications were identified, which underlines the global interest of the scientific community for this concept (see Table I).

Climatology and sustainable development

It must be noted that vulnerability seems to meet a growing interest in the scientific community as shown on Some conclusions appear to be interesting, even at a first reading of this short survey of the Web of Science. Of these 534 publications, 86% were related to only two scientific topics (health, climatology and sustainable development) [START_REF] Blaikie | Nepal in Crisis: Growth and Stagnation at the Periphery[END_REF]. Moreover, this survey enlightens the lack of use of the concept of vulnerability in industrial engineering (only 11 publications out of 534; i.e. 2%), which motivates even more to work on this concept in accordance with project management principles.

But following the general trends of this short survey, the following state of the art is firstly carried out separately on the two most contributing topics: "health" and "climatology and sustainable development". Finally, it focuses on some works about vulnerability in the fields of industrial engineering and project management.

Focus on the two most contributive fields: "health" and "climatology and sustainable development"

As suggested by the short survey previously presented, a first literature review was conducted over research works dealing with health or climatology and sustainable development issues. First, it can be observed that some research works relate vulnerability to the presence of weaknesses (Luers, Lobell et al. 2003), [START_REF] Scoones | Sustainable rural livelihoods. A framework for analysis -IDS[END_REF], [START_REF] Ellis | Rural Livelihoods and Diversity in Developing Countries[END_REF]. These weaknesses can be of different nature, and can for instance impact the activities, assets and outcomes of a system, as shown by Figure 2 [START_REF] Ellis | Human Vulnerability and Food Insecurity:Policy Implications Forum for Food Security in Southern Africa[END_REF].

Figure 2. Vulnerability based on assets, activities and outcomes given a specific context [START_REF] Ellis | Human Vulnerability and Food Insecurity:Policy Implications Forum for Food Security in Southern Africa[END_REF] Second, other papers insist on an aspect of vulnerability, which is the coexistence of conditions of exposures to stresses / dangers and of a state of non-capacity to cope with them. This is notably the case of (Maskrey, 1989) with natural hazards, [START_REF] Shi | The convergence of vulnerable characteristics and health insurance in the USA[END_REF] when adressing healthcare systems, or (Ezard, 2001) in the case of drug addiction. Particularly, several works detail the notion of exposure [START_REF] Watts | The space of vulnerability: the causal structure of hunger and famine[END_REF][START_REF] Blaikie | At risk[END_REF], notably in contexts of crisis. This two-side aspect of vulnerability can be synthesized using the definition of Chambers (Chambers, 1983): vulnerability is "the exposure to contingencies and stress, and difficulty coping with them. Vulnerability has thus two sides: an external side of risk, shocks and stress to which an individual or household is subject; and an internal side which is defencelessness, meaning a lack of means to cope without damaging loss". This expresses that damages (turned out consequences of risks) can be understood as the coincidence between a dangerous event and a vulnerable ground. This coexistence is notably modelled using stressor/receptor models, such as the one in Figure 3. Moreover, other works detail the non-capacity to cope with possibly damaging events in terms of resistance and resilience, that is to say how individuals, groups or parts of a system can resist to vulnerability, instantly or when recovering [START_REF] Perry | Voices of beneficiaries: Medicare Part D insights and observations one year later, Kaiser Family Foundation report[END_REF], [START_REF] Dibben | Human vulnerability in volcanic environments: the case of Furnas, Sao Miguel, Azores[END_REF], [START_REF] Kelly | Assessing vulnerability to climate change and facilitating adaptation, Centre for Social & Economic Research on the Global Environment[END_REF]. Finally, it can also be oserved in the literature that vulnerability is in essence context-dependent as underlined by [START_REF] Strauss | Processes of healing and the nature of schizophrenia. Towards a comprehensive therapy for schizophrenia[END_REF], [START_REF] Ellis | Human Vulnerability and Food Insecurity:Policy Implications Forum for Food Security in Southern Africa[END_REF] who insist on its evolution over time and its people-dependent perception.

Focus on industrial engineering, including project management

Theys underlines that in the field of industrial engineering and management, "there are still too few languages and tools for analysing vulnerability" [START_REF] Theys | La société vulnérable. La société vulnérable. Evaluer et maîtriser les risques[END_REF], which motivates to develop them. However, some attempts were already done, like for instance [START_REF] Bogataj | Measuring the supply chain risk and vulnerability in frequency space[END_REF] who place the notion of vulnerability at the centre of the value creation process, which is consistent with [START_REF] Schneider | Fences and Competition in Patent Races[END_REF]. In order to understand this possible degradations during the value creation process, systems thinking-based models were developed [START_REF] Hellström | Critical infrastructure and systemic vulnerability : Towards a planning framework[END_REF]. Particularly, the works of Durand [START_REF] Durand | Management des risques dans les organisations industrielles complexes: prépondérance de la dimension managériale dans la genèse des vulnérabilités[END_REF], which follow a complex systems approach, define vulnerability as the "extent to which an organisation is able or not to cope with the dangers it is exposed to". This work explains that working on the notion of vulnerability permits to focus on an organisation's ability to resist to hazards and on the mechanisms that can weaken or strengthen its overall functioning, behaviour and evolution. This also underlines that possibly damaging events should be handled in accordance with their possible impact on the core values of a project (or a system), given its complex structure.

Synthesis: list of vulnerability characteristics

Before continuing, we propose to list down the main characteristics of vulnerability which can be synthesised after our state of the art:

• Vulnerability is in essence relative to a system which has weaknesses which can alter its trajectory to reach its objectives.

• Vulnerability corresponds to the coexistence of a level of exposure (or a susceptibility to be exposed) to stressors and a non-capacity level to cope with these stressors.

• Two aspects of the system's non-capacity are to be underlined:

o Static vision: Resistance of the system regarding the apparition of the stressor.

o Dynamic vision: Resilience of the receptor corresponding to the recovering of the system.

• A system's vulnerability is in essence context-dependent and evolves over time, notably because of the changes over time in the systems' characteristics due to its natural evolution and the apparition of stressors.

Each of these aspects is therefore to be present in the definition of project vulnerability or/and its associated models and tools.

Preliminary step: Defining the concept of project vulnerability and linking it with the concept of risk

Even though a lack of consensus can be observed around the notion of vulnerability (Luers, Lobell et al. 2003), the state of the art which was conducted led us to propose the following definition for project vulnerability. We claim that this concept permits to analyse a project system and focus on its existing weaknesses thanks to a systems thinking-based approach (Le Moigne 1990). Project vulnerability is then "the characteristic of a project which makes it susceptible to be subject to negative events and, if occurring, which makes it non capable to cope with them, which may in the end allow them to degrade the project values". Project non capability to cope with negative events when occurring includes non-resistance (instantaneous damages) and resilience (recovery over time). Moreover, project vulnerability exists if and only if project susceptibility to be subject to negative events and project non capability to cope with them coexist, i.e. if and only if they simultaneously exist at a given time.

As shown on Figure 4, project vulnerability is then linked with the traditional concept of project risk due to this coexistence possibility (linked to risk probability) and the damages which can occur (linked to risk impact).

Figure 4. Project risk as an impact due to coexistence

As a whole, project performance degradation is the consequence of two coexistences. The first one conditions the apparition of vulnerability: coexistence of susceptibility to be subject to negative events and incapacity to cope with them if occurring. The second one is the temporal coincidence of a triggering event and a vulnerable ground for a risk to occur and to degrade the processes of values creation during the project.

Now that these coexistences are cleared, the aim of this work is to propose a systems thinking-based model of vulnerability to assist complex project risk management. The aspect of susceptibility is neglected in the following section since susceptibility is closely linked to probabilistic aspects of possible negative triggering events, which we do not aim at addressing here. The aim of the next section is to focus on the project system weaknesses and thus on the identification, evaluation and management of non-capabilities in terms of resistance and resilience. As a whole, this section thus proposes a paradigm shift since it focuses on the project system existing elements instead of focusing on possible events.

A methodology to model and manage project vulnerability

Our methodology to handle project vulnerability is the following:

• Project vulnerability identification o Identifying the objectives of the project in terms of values creation.

o Identifying elementary vulnerable processes and elements of the project systems (vulnerable tasks, actors, resources, etc…).

• Project vulnerability analysis

o Assigning a contribution rate of any of these elements to each value creation process.

o Identifying possible triggering events which can damage a given project vulnerable element and analysing its resistance and resilience through a stressor/receptor model.

• Project vulnerability response plan to cure the weaknesses of the project system and prevent it from possible damages.

• Project vulnerability monitoring and control activity to watch over the project evolution.

As a whole, these four steps are to constitute the project vulnerability management process (Figure 5), which appears to be similar to the existing project risk management processes as defined in (IEC 1995;[START_REF] Apm | Project Risk Analysis & Management (PRAM) Guide. High Wycombe[END_REF]IEEE 2001;BSI 2002;AFNOR 2003;ISO 2003;[START_REF] Pmi | A guide to the project management body of knowledge (PMBOK)[END_REF][START_REF] Ipma | IPMA Competence Baseline (ICB), Version 3[END_REF]. Each of them is developed in the following paragraphs.

Figure 5. The project vulnerability management process

The project vulnerability identification step

In order to identify properly project vulnerabilities, the use of systems thinking is proposed. It must be underlined that vulnerability permits to focus on the project system (its processes, elements, structure,…) which makes project vulnerability a more tangible concept than project risk. For all practical purposes, identifying project vulnerabilities means identifying the weaknesses of a project system which make its values creation vulnerable. In order to do so, a four step processes bases on the systems thinking (Le Moigne 1990; Genelot 2001; Vidal and Marle 2007; Vidal and Marle 2008) approach is proposed. Vulnerability is identified at three levels

•
The teleological pole of the project system, which permits to identify the vulnerable stakes of the project (targeted created values).

• The functional pole of the project system, which permits to identify the vulnerable processes / tasks of the project system.

• The ontological pole of the project system, which permits to identify the vulnerable elements (actors, resources, inputs of processes, …) of the project system.

Then follows a reflexion on a stressor / receptor model to identify project process vulnerabilities which are defined as triplets (value, process, event) and project elementary vulnerabilities which are defined as triples (value, element, event).

This means that the genetic aspect (evolution of the project system) is also to be considered. Indeed, whenever the project phase changes, or whenever considerable changes in the project system occur during a project phase, the vulnerability identification process is to be performed again, or at least refined / updated. As a whole, this approach helps to reduce ambiguity and doubts on usefulness since everything is drawn by the final objectives of the project, that is to say values creation.

Identification of vulnerable values, processes and elements through systems thinking

A project is vulnerable if and only if one of its objective values may not reach its target. That is why we argue that project vulnerability should be addressed regarding each value of a given project, in order to underline the different possible kinds of damages within the project. In the end, the first deliverable of the project vulnerability identification step is a three-level hierarchical structure composed of (see Figure 6):

• The project values which are likely to be damaged and make thus the project vulnerable regarding them.

• For each value Vi, the project processes/tasks which contribute to Vi creation. These processes are likely to be altered (and thus to be vulnerable) by negative events, which makes as a consequence the project vulnerable regarding Vi.

• For each process Pij, the project elements which permit to perform Pij (actors, resources, other inputs).

These elements are likely to be altered (and thus to be vulnerable) by negative events, which alters Pij, which makes as a consequence the project vulnerable regarding Vi.

An arborescence is thus built to classify project vulnerable values, processes and elements as shown hereunder on Figure 6. One should note that this decomposition is analogous to the one mentioned in 2.2 and proposed in [START_REF] Ellis | Human Vulnerability and Food Insecurity:Policy Implications Forum for Food Security in Southern Africa[END_REF] in terms of outcomes (values), activities (processes) and assets (project elements).

Figure 6. Levels in the project vulnerability identification step However, some work is still to be done to identify project vulnerabilities as one can talk of vulnerability only if mentioning the event something is vulnerable to.

Identification of process and elementary vulnerabilities

Let (V1, V2, …, Vn) be the set of values created by the project. For each Vi, we have identified the corresponding vulnerable project processes and elements. Each value Vi can be weighted by a coefficient αi which permits to set priorities in the values creation processes (the sum of all these coefficients is equal to 1). If αi > αj, then project vulnerability regarding value Vi is all the more important to control than project vulnerability regarding value Vj since the creation of Vi is preferred to the one of Vj. Such weights are notably to be set by project stakeholders, by the project management office or by the firm, notably thanks to the consideration of strategic or tactical aspects.

Given a value Vi, as mentioned before, there are several project processes/tasks (Pi1, Pi2, …, Pip) which contribute to Vi creation. In the same manner, the project manager, the project team or external experts can permit to determine weights βij which permit to determine the importance of each task regarding Vi creation (for each i, the sum of all βij is equal to 1). At this stage, one should particularly notice that tasks can contribute to several values creation processes.

The same work can be done on every category of project elements. In the end, determining all the weights in the hierarchical structure (by expertise or experience) permits to determine the maximum possible degradation linked to a project element/process if it is altered. This first analysis thus permits to neglect aspects which can be neglected due to their low implications in possible damages regarding values creation. This is all the more important to perform since the combinatorial aspects of project vulnerability identification are likely to be very important.

Once refined, we claim for the use of a stressor / receptor model to identify key project vulnerabilities, that is to say key project process vulnerabilities which are triplets (value, process, event) and key project elementary vulnerabilities which are triplets (value, element, event). The first steps of the identification process permitted to identify project values, processes and elements and to refine their lists thanks to issues about contribution rates to values creation. This work now proposes that, given a process or element, one focuses on this process / element as a receptor and tries to list down as exhaustively as possible the possible negative events it may be exposed to (that is to say its potential stressors). This aspect is to be performed thanks to the conjoint use of expertise and experience. We may recommend here the use of some creativity methods such as brainstorming, dissociation or inversion. As a whole, an initial list of project process and elementary vulnerabilities is done. Identifying project vulnerabilities is in itself a first result. However, one should be able to evaluate/analyse them in order to manage them better.

The project vulnerability analysis step

Once the set of project process or elementary vulnerabilities is identified, theses ones are to be analysed regarding the two principal aspects of vulnerability in terms of non-capability, that is to say resistance and resilience. In order to do so, objective scales should be built up.

A first tool is proposed: objective 1 to 10 Likert scales should be built by experts, like in the risk analysis process when performing the evaluation of probability and impact (see examples in Figure 7). This figure also shows how synthetic diagrams (non-resistance and resilience on axes, contribution rate to the project value V as the diameter of the circle) can be built to highlight principal project vulnerabilities. We recommend that in a diagram, there should be only the project vulnerabilities which correspond to a same value possible degradation, so that the analysis of this diagram is of interest for management use.

Figure 7. Project vulnerability analysis

In the end, a global index can be calculated in order to give a simple indicator to rank project vulnerabilities regarding a project value V. Let CR(V) be the contribution rate (percentage of the project value) of the vulnerable element/process which is addressed. Let NR be the evaluation of its non resistance. Let R be the evaluation of its resilience. Then, a synthetic aggregated measure (which can help to underline higher priority vulnerabilities), which we name the Crucial Index Γ(V), is given by the following equation (Γ(V) varies between 0 and 100).

) ( ) ( V CR R NR V × × = Γ
As during any aggregation operation, part of information is lost. Indeed, several different triplets can have the same value when multiplying the values of its elements. As a consequence, when ranking according to the Γ(V) index, one may rank at the same level several triplets which could not be handled the same way (for example high non-resistance and low resilience versus low resilience and high non-resistance with the same value of Γ(V)). In the end, this classification according to Γ(V) should always be considered with the initial evaluation of NR, R and CR(V) in order to make more relevant decisions during the project vulnerability response plan step.

The project vulnerability response plan step

The project vulnerability response plan step permits to decide on the actions which are needed to reduce the threat of the existence of project process or elementary vulnerabilities. The project vulnerability response is to determine the overall strategy for strengthening a project. As in the risk management process [START_REF] Pmi | A guide to the project management body of knowledge (PMBOK)[END_REF], even though slightly different, there are five basic strategies to cope with project vulnerabilities.

Mitigation

Mitigation is the strategy which consists in making decisions in order to improve the resistance of the project processes / elements and / or to lessen their resilience regarding negative triggering events. Another strategy would be to diminish the contribution rate of the process / element to the value creation but whenever possible, this strategy is to be classified under the name of transfer since contributions are transferred to other entities.

Avoidance

Avoidance is the strategy which consists in making decisions in order to eliminate totally project vulnerabilities.

The reader should note that for project risk management, there are two ways to avoid risks (reducing to 0 probability or impact) but there is only one way to avoid vulnerability (reducing to 0 non-resistance). Indeed, resilience has no direct impact on avoidance since resilience underlines a dynamical aspect (evolution over time).

Transfer

Transfer is a strategy which consists in making decisions in order to transfer project vulnerabilities to other project processes/elements which have less influence in the values creation processes. This strategy is really different than the transfer strategy in the project risk management process which consists in the transfer of the risk responsibility to a third party.

Here, vulnerabilities exist within the project system and there is no reason to transfer them to third parties which would be external to the system (however, one should note that decisions can still be made to transfer the final risk responsibility to any of the project stakeholders). However, transfer strategies can be defined within the project. For instance, if an actor appears to be vulnerable, then one can choose, whenever possible, to transfer this actor to other processes which have less impact on the creation of project values. The transfer strategy is thus the strategy which proposes to handle contribution rates (to the corresponding value creation) as potential levers for vulnerability reduction.

Acceptance

Acceptance is a strategy which is notably designated for low resilience and high resistance project vulnerabilities. It consists in saying that little or nothing can be done expect letting things run their course, knowing that these low Crucial Index vulnerabilities however exist.

Contingence

Contingence response is an intermediary manner to cope with vulnerabilities. It is associated with the one of the other strategies (especially mitigation) and determines the actions which should be done if the chosen vulnerability response should fail.

The project vulnerability monitoring and control step

In essence, a project system is evolving, which means that project vulnerabilities do not remain static. New vulnerabilities may pop up, the characteristics of project vulnerabilities may change or vulnerability responses may not have the effects which were planned. Vulnerabilities are then to be re-identified and re-assessed during the project, since they refer to a project system which is in essence in constant evolution.

Synthesis : comparison with the project risk management process

Table II. proposes a critical comparison of the project risk management process and the project vulnerability management process.

Table II. Comparison between project risk and vulnerability management processes

As a whole, this approach may diminish the observed (in fieldwork) reluctance to risk management processes as vulnerability management processes focus on existing tangible aspects of the project. When possible risks were underlined before, existing weaknesses of the project are stressed thanks to this approach. In the end, the vulnerability response plan may thus appear more relevant as the responses directly focus on the project system instead of dealing with probabilistic events. The required efforts (notably in terms of time and money) for these responses may thus appear more necessary, for existing project weaknesses are underlined.

Case study

A case study is performed during the FabACT project [START_REF] Vidal | Using the AHP to select anticancer drugs to produce by anticipation[END_REF]), a software development project within the context of the pharmaceutical industry. This project was executed in collaboration with the Georges Pompidou European Hospital.

Introduction

The French health system faces ever growing demands under very pressuring conditions as it is much constrained in a complex environment. In our case, production volumes at the chemotherapy compounding unit (UPIO) have drastically increased (5% in a two years time). To support this increasing workload without extra staff, pharmacists wanted to evaluate how anticipating the production of certain drugs may help them in improving the organisation of the production process.Within this context, the FabACT project (Figure 8) has been launched at HEGP Pharmacy department in 2006. The aim was to achieve a better balance between the workload and the ability to hold the admixture compounding burden while respecting constraints such as drug stability and quality of service. The deliverable of the FabACT project was a decision support tool in order to

Project risk management process

Project vulnerability management process

Identification step

One step process as it Identifies possible triggering events, and often their effects and their causes. Notice these events can be either positive or negative. Performed through expertise / experience / creativity.

Two main step process as it first identifies existing tangible aspects of the project system which appear to be vulnerable regarding the project values creation processes. Then it identifies project process or elementary vulnerabilities. First step performed through expertise, seconde one through expertise / experience / creativity.

Analysis step

Evaluates risk probability and impact. Numerous methods to perform such quantitative or qualitative analysis. Classification is proposed to focus on high priority risks, notably thanks to the definition of a criticality index. One of the main difficulties is to assess possible events.

Evaluates the resistance and resilience of project vulnerabilities. First proposal is a qualitative analysis.

Classification is proposed to focus on high priority vulnerabilities thanks to the definition of a 0 to 100 cruciality index. One of the main difficulties is to assess resistance and resilience regarding possible events.

Response plan step

Proposes strategies for risk responses. Leaves possibilities for risk mitigation, avoidance on two factors (probability/impact), acceptance, contingence or transfer to a third party.

Proposes strategies for vulnerability responses. Leaves possibilities for vulnerability mitigation, avoidance on a single factor (resistance), acceptance, contingence and transfer within the project system.

Monitoring and control step Very similar to one another Very similar to one another assist pharmacists while choosing the anti-cancer drugs that can be produced in advance. Due to the sensitivity of this project, its vulnerabilities were studied.

Results and discussion

Identification of project vulnerabilities

The project values were listed as the following ones:

• Completion of the project on time

• Profit due to the project

Conclusions and perspectives

As a whole, this article presents an innovative way to assist project risk management through the integration of the concept of project vulnerability. This concept permits to analyse a project system and focus on its existing weaknesses thanks to a systems thinking-based approach. After proposing a definition and a description of project vulnerability, a proposition to describe the project vulnerability management process into four successive steps is done. The reader should remind them as a first proposal to perform project vulnerability analysis:

This project vulnerability management process permits to concentrate directly on the existing weaknesses of a

project system which may create potential damages regarding the project values creation. By focusing on this system, response plans may be more adapted to the existing lacks of the project, as shown by the case study with the FabACT project. Such focus on the system is to be of great interest for project managers and project teams.

When before there was ambiguity or lack of confidence in dealing with potential events and potential impacts, vulnerability management permits to point out the weaknesses of a project. Attention should however be paid on vulnerability communication so that it is not seen as a way to underline low performance elements or actors in a project. Vulnerability management must therefore be highlighted as a promising tool for complex project performance management as it permits a more effective and efficient accompaniment of project teams thanks to a better understanding of possible damage creation within complex project systems. Some aspects of this work may however be discussed. We thus identify several research perspectives to consolidate the proposals of this chapter:

• First, the susceptibility aspect of vulnerability is neglected in this first approach of project vulnerability management. Future research work may explore this concept.

• Moreover, the calculation of the Crucial Index Γ(V) is to be improved thanks to the integration of multicriteria aspects

• Other promising works may focus on the evaluation of the non-resistance and resilience of project vulnerabilities, notably thanks to the introduction of interdependences which exist in complex project systems.

Figure

  Figure 1 below.

Figure 1 .

 1 Figure 1. Web of Science publications the title of which contains the word vulnerability (

Figure 3 .

 3 Figure 3. Vulnerability study thanks to a stressor/receptor model (de Fur, Evans et al. 2007)]

Figure 8 .

 8 Figure 8. Work Breakdown Structure of the FabACT project

Table I .

 I Occurrences of the word vulnerability in the Web of Science publications in 2007

	Topic	Total Global matter of interest	Number of articles
	Health	269 Psychology and psychiatry (and behaviour factors)
		Disease factors
		Genetics
		Response to treatment
		Disease transmission
		Diagnosis fiability
		Global organs fragility
		Healthcare management
		Morbidity factors and evaluation

By going back to processes and tasks, it is possible to build up a table which synthesises the contribution of any task to any of theses values creation (Table III). This table permits, as suggested, to refine the analysis of fewer tasks / processes and project elements (corresponding to theses tasks and processes) when performing the project vulnerability analysis.

Table III. Identifying project tasks contribution to project values creation

We identify the tasks which have significant contribution rates regarding the creation of this value (over 10% in orange, over 5% in yellow). Only the vulnerability of these tasks is then to be analysed further as a first result since if other tasks are altered because of their vulnerability, they can in the worst case alter less than 5% of the scientific quality of the project deliverables. This step is absolutely necessary in order to lessen the combinatorial aspects of a project vulnerability study.

In order to close the vulnerability identification steps, we then identify the project elements which contribute to the identified tasks. In the same manner, contribution rates tables can be built. The reader will find an example of such a table of elementary vulnerabilities in Table IV (for the creation of high scientific quality deliverables). In the end, a list of vulnerable tasks and associated project elements (here actors) is built. This list is to be analysed in the following step as an illustration on how to perform project vulnerability analysis.

Table IV.

Identifying the actors which contribute more to the tasks which make the project vulnerable regarding scientific quality creation

Analysis of project vulnerabilities

We now study resilience and resistance in order to quantify their weakness regarding possible negative events.

For instance, one can perform it here on the identified project actors which make the project potentially vulnerable regarding the creation of high scientific quality deliverables. We obtained a list of five actors which contribute significantly to this value creation: ACTOR 1, ACTOR 2, ACTOR 3, ACTOR 6, ACTOR 7. These actors are the ones to be watched over because of their potential impact on the targeted value creation if their usual behaviour during the project is altered. One is to find hereunder an excerpt of the FabACT project actor vulnerability analysis (Table V). The project actor vulnerabilities are ranked according to their Crucial Index Γ(V).

Table V. Excerpt of the FabACT project actor vulnerability analysis

Vulnerability response plan

This analysis underlines here that ACTOR 1 is the most vulnerable one regarding scientific quality creation during the project. The vulnerability response plan should therefore focus on the accompaniment of this actor in order to guarantee its performance regarding value creation or it should propose transfer strategies which transfer some tasks to less vulnerable actors. This analysis permits to underline that ACTOR 1 is particularly vulnerable to problems regarding the requirements of the software (whether they are unclear, changing or potentially misunderstood). As a consequence, this underlines that particular attention should be given to the definition of requirements and specifications as they are likely to condition. Other specific attention should be paid to the event "misunderstanding of the publication target requirements" since it directly impacts several actors in the FabACT project regarding scientific quality creation. This can be understood since the FabACT project is at the meeting point of industrial engineering and pharmacy and that publication targets requirements may not always be clear in the possible integration of articles dealing about this issue in the corresponding journal or revue.

Comparison with a traditional risk management process

Once can find hereunder an excerpt of a traditional FMECA performed for the FabACT project (Table VI) to be a point of comparison in order to underline the potential benefits of a project vulnerability analysis.

Table VI. Excerpt of the FMECA of the FabACT project

First, one should notice that the lack of integration of project values does not permit to understand properly the consequences of the potential failure modes, even though there effects are likely to be mentioned. Vulnerability analysis permits to understand better the possible damage chains which exist within a project. It must be noticed that for instance, no aspect about publication target requirements had been mentioned in the FMECA although it appeared to be a high potential source of vulnerability regarding scientific quality creation. Second, by analysing the project system's weaknesses, one is to make better and more specific decisions when establishing a response plan. Indeed, the FMECA mentions "unclear software requirements and specifications" or "misunderstanding of software specifications" as potential causes of important failure modes. This is consistent with the project vulnerability analysis which was performed. However, the project vulnerability analysis permits to focus on the project elements or processes which are impacted the most by this potential cause / stressor event. For instance, actors did not appear equally vulnerable to these events, which permitted to concentrate on the weakest parts / actors / processes of the project.