Modèle ALO-E de description du projet
3.1.2. Notre proposition : le référentiel de complexité projet
Ce référentiel est inspiré de la dichotomie de Baccarini (complexité organisationnelle et complexité technologique) et de la description des facteurs de complexité nécessaires et non suffisants développés par Edmonds (1999) : taille du système, diversité et nature des éléments du système, interactions dans le système, ignorance et incertitudes dans le système.
Nous avons bâti dès lors un référentiel de complexité projet qui peut servir de base à l’identification, la compréhension, la maîtrise et la prédiction des sources et des phénomènes de la complexité projet. Il peut également être utilisé pour l’évaluation de la complexité d’un système projet, et nous nous en servirons dans la section 4.2. Il est constitué de quatre familles de facteurs (Figure 29).
Figure 29 : Les quatre familles de facteurs de complexité
Nous avons répertorié certains facteurs dans chacune des huit cases du Tableau 3. Ce référentiel a été validé et simplifié lors d’une étude Delphi. Les détails relatifs à cette étude sont donnés en annexe dans les articles 9.2 (ESWA, pages 146 et suivantes) et 9.3 (IJTM, pages 180 et suivantes), à savoir les questions posées, le panel d’experts et l’analyse de leurs réponses. Les facteurs qui ont été conservés dans le référentiel final sont ceux qui ont obtenu une note suffisamment élevée, ce qui correspondait à un consensus suffisant pour les experts. La simplification se justifie d’un point de vue opérationnel car il est difficilement envisageable dans le cadre d’un projet d’analyser 70 facteurs de complexité, alors qu’il est plus facile de s’occuper des 18 plus importants.
Elaboration d’un référentiel de complexité projet Page 59 Tableau 3 : Description complète du référentiel de complexité
Famille Type Complexité Organisationnelle Type Complexité Technologique
Taille
Amplitude du capital investi Largeur du périmètre projet Durée du projet
Nombre et quantité de ressources (matérielles et technologiques)
Largeur du périmètre projet (organisationnel) Nombre d'activités dans le projet
Nombre de décisions à prendre Nombre de départements impliqués Nombre de livrables
Nombre de niveaux hiérarchiques Nombre de parties prenantes
Nombre de structures, groupes et équipes à coordonner Nombre de systèmes d'information
Nombre d'entreprises / projets partageant les ressources Nombre d'investisseurs différents
Nombre d'objectifs
Nombre et quantité de ressources (humaines)
Taille de l'équipe
Diversité
Diversité de l'équipe (expérience, milieu social, etc…) Diversité des compétences techniques requises Diversité de statuts des parties prenantes Diversité des composants du produit Diversité des compétences organisationnelles requises Diversité des dépendances technologiques Diversité des interdépendances organisationnelles Diversité des ressources utilisées
Diversité des intérêts des parties prenantes Diversité des technologies utilisées pendant le projet Diversité des moyens financiers
Diversité des niveaux hiérarchiques dans l'organisation Diversité des outils et méthodes de gestion de projet appliqués
Diversité des systèmes d'information
Localisation géographique des parties prenantes
Interdépendances
Coopération et communication au sein de l'équipe Dépendances entre processus technologiques Dépendance avec l'environnement Interdépendances entre les composants du produit Dépendances entre les calendriers Interdépendances entre les spécifications du projet Disponibilité des ressources partagées (matérielles et
humaines)
Interdépendances entre ressources matérielles et matières premières
Dynamique de l'évolution de la structure de l'équipe Interconnexion et boucles de retour dans les réseaux de projet (tâches)
Interdépendance des processus Interdépendances entre acteurs Interdépendances entre objectifs
Interdépendances entre sites, départements et entreprises Interdépendances entre systèmes d'information Interrelations entre parties prenantes Niveau d'interrelation entre phases
Nombre d'interfaces dans l'organisation projet Relations avec l'organisation permanente
Transport combiné
Contexte
Complexité organisationnelle de l'environnement Besoin de créativité
Concurrence (organisation) Complexité technique de l'environnement Configuration et diversité culturelle Concurrence
Configuration organisationnelle de l'institution qui
supporte le projet Configuration et diversité culturelle (technique) Degré d'innovation organisationnelle
Configuration technologique de l'institution qui supporte le projet
Lois et normes locales (organisationnelles) Degré d'innovation technologique Nouvelles lois et normes (organisationnelles) Lois et normes locales
Nouvelles lois et normes Possibilités de développement Relation à un calendrier public
Nota : Même si le tableau initial comprend 70 éléments, il est toujours possible d’en rajouter en fonction des évolutions ou du contexte particulier de l’entreprise qui l’utilise. De plus, 70 % des facteurs se trouvent dans la catégorie complexité organisationnelle.
Elaboration d’un référentiel de complexité projet Page 60 Le principe de Pareto a été appliqué afin de garder les entrants minoritaires qui génèrent la majorité des sorties, ici les notes attribuées par les experts. Une moyenne minimale de 4,5 sur 5 a été choisie afin de retenir environ 20-25% du référentiel initial. Il est évident que cela prête toujours à question de savoir pourquoi le 19e n’a pas été pris, ou de savoir pourquoi 18 et pas 16 ou 20. Il n’y a pas de réponse parfaite à cette question, simplement un choix qui a permis de se trouver dans une zone où le nombre de facteurs à considérer reste gérable et avec un écart significatif entre le dernier pris et le premier non pris. Tout ceci reste bien sûr subjectif, et même la validation par les 18 experts n’est pas une garantie absolue, puisqu’eux-mêmes sont soumis à leur propre subjectivité et le choix du panel d’experts a lui aussi été soumis à notre subjectivité. C’est aussi pour cela qu’il est conseillé de partir à chaque situation nouvelle (nouvelle entreprise, nouveau type de projet) du référentiel global pour valider un référentiel simplifié adapté, et notre liste de 18 est une proposition qui permet de ne pas partir de la feuille blanche, mais qui peut être amendée. Si l’industriel souhaite absolument repêcher le 19e, cela ne pose pas de problème. S’il souhaite repêcher le 70e, il doit être conscient que ce facteur n’a pas fait l’unanimité chez un panel d’experts de la question, il risque donc d’être moins pertinent que les autres. Pour résumer, nous ne prétendons pas prendre la décision à la place du décideur, mais simplement l’aider en lui fournissant dans le Tableau 3 une pré-liste complète et dans le Tableau 4 une pré-liste simplifiée avec la justification (note moyenne de reconnaissance par les experts). Par exemple, il est courant que l’apparition d’une nouvelle norme dans les projets automobiles ait des répercussions majeures, sur beaucoup de domaines, beaucoup de composants, beaucoup de tâches et beaucoup d’acteurs. Il serait alors normal de considérer ce critère dans la liste contextualisée.
Tableau 4 : Description du référentiel simplifié de complexité
Famille Type Complexité Organisationnelle Type Complexité Technologique Taille
Nombre de parties prenantes
Diversité
Diversité des intérêts des parties prenantes Diversité des systèmes d'information
Localisation géographique des parties prenantes
Interdépendances
Dépendance avec l'environnement
Interdépendances entre les spécifications du projet
Dépendances entre les calendriers
Disponibilité des ressources partagées (matérielles et humaines) Coopération et communication au sein de l'équipe
Interconnexion et boucles de retour dans les réseaux de projet (tâches)
Interdépendances entre objectifs
Interdépendances entre sites, départements et entreprises Interdépendances entre systèmes d'information Niveau d'interrelation entre phases
Contexte
Complexité organisationnelle de l'environnement Complexité technique de l'environnement Configuration et diversité culturelle
Elaboration d’un référentiel de complexité projet Page 61
3.1.3. Applications du référentiel de complexité
Il existe trois grandes applications possibles de ce référentiel, qui dépendent du moment où est faite l’analyse. L’analyse prédictive de complexité projet. C’est une évaluation a priori de la complexité d’un projet, ou de la complexité relative d’un projet par rapport à un autre. La section 4.2 montre un exemple de travail dans ce domaine. Une thèse est planifiée pour la rentrée 2011 sur ce sujet avec le CEISAR, Center of Excellence for Information Systems and Architecture et une ou plusieurs entreprises servant de terrain d’application parmi Axa, Total et Air France (à la suite du stage master de Sergio Alonso). L’idée est d’ajouter le critère complexité dans l’étude d’impact d’un projet et notamment dans son évaluation multi-critères au moment de la sélection.
L’autre idée est d’assister le démarrage du projet une fois celui-ci sélectionné, car les premiers éléments d’information et les premières décisions préliminaires conditionnent fortement les autres livrables que sont la WBS, le planning, le budget, etc… et donc la façon dont le projet va se dérouler et quel résultat il a des chances de délivrer (Gareis 2000 ; Dvir et al. 1998). Utiliser notre référentiel en avant-projet ou phase préliminaire de projet comme une check-list permettant d’identifier des sources possibles de complexité influencera positivement certaines décisions qui pourraient être prises trop tôt alors qu’il faudrait laisser encore des degrés de liberté tant que certaines hypothèses ne sont pas levées. De même, certaines décisions pourraient être jugées comme apportant trop de complexité, que ce soit par le nombre d’éléments, leur diversité ou leurs interdépendances.
L’analyse en diagnostic de la complexité projet. C’est une évaluation en cours de route du projet, qui permet d’anticiper certains phénomènes possibles à partir de la photographie instantanée et d’envisager un certain nombre de décisions correctrices. Cela repose sur des méthodes traditionnelles de pilotage de projet et d’analyse de risques en plus de la focalisation sur la complexité et des méthodes spécifiques que nous proposons. L’idée est de ne pas focaliser sur un seul paramètre ou une seule dimension du projet, ce qui peut conduire à des résolutions partielles de problème et donc des échecs ou a minima des gaspillages (Shenhar et Dvir 2007). Nous permettons d’avoir une vue plus globale, à la fois d’un point de vue local puisqu’on s’intéresse à plus de paramètres en même temps, mais également d’un point de vue global puisqu’on s’intéresse à des propagations et donc des effets indirects du problème d’origine. L’implication d’un changement par exemple, qu’il soit demandé ou subi, permet d’anticiper l’ensemble de ses conséquences potentielles, négatives et positives, directes et indirectes. On mixe ici l’analyse de la situation présente et l’anticipation de la situation future telle que présentée dans le paragraphe précédent. Une collaboration est en cours avec Marija Jankovic et Gilles Turré (ex-PSA Peugeot-Citroën) sur l’analyse des impacts indirects d’une demande initiale d’innovation dans un projet, que ce soit une innovation produit, une innovation organisationnelle ou méthodologique. Elle a fait l’objet d’une publication dans la conférence ESREL European Safety and Reliability 2011 (non incluse dans ce mémoire). Dans le cas de projets de développement par exemple, l’anticipation des conséquences de telle ou telle décision ou tel ou tel changement, qu’il soit voulu en interne ou requis par une autre partie prenantes, permet d’éviter certains problèmes dont le gaspillage (rework), le non respect de certaines spécifications projet et/ou produit (Austin et al. 2002 ; Clarkson et al. 2004 ; Steffens et al. 2007 ; Shenhar 2007 ; Lindkvist 2008).
L’analyse a posteriori de la complexité projet. Il s’agit ici d’assister la phase de fermeture et de retour d’expérience du projet. Cela consiste à retracer les facteurs de complexité qui existaient au cours du projet et leur impact avec les évènements positifs et négatifs enregistrés pendant ce projet. Ce processus d’apprentissage d’un projet sur l’autre est vital, notamment dans le cadre de projets complexes, où la corrélation entre les causes et les effets est d’autant plus difficile à établir (Williams 2003). Nous utilisons cette approche chez Renault dans le cadre du stage master d’Antoine Sévely pour établir le lien entre des problèmes réels d’un projet passé et les causes liées à la complexité, notamment liées à une propagation non maîtrisée entre paramètres produit et projet.
Elaboration d’un référentiel de complexité projet Page 62
3.1.4. Conclusion intermédiaire
Nous avons travaillé sur la notion de complexité projet, en introduisant quatre familles de facteurs que sont la taille, la diversité, les interdépendances et le contexte. Ils sont organisés selon deux types de complexité : la complexité organisationelle et la complexité technologique. Ces facteurs ont été rassemblés en un référentiel de complexité, qui se décline en une version simple à 18 facteurs et une version complète mais plus difficilement exploitable à 70 facteurs. Il est à noter que la majorité des facteurs sont relatifs à la complexité organisationelle. Au final, il s’agit donc pour un chef de projet de savoir comment reconnaître et saisir des opportunités qui pourraient émerger de cette complexité, et également de savoir éviter ou au moins réduire les effets négatifs de cette complexité. C’est ce qui justifie nos travaux, depuis la modélisation de la complexité jusqu’à la prise de décision en milieu complexe, en passant par des étapes d’analyses complémentaires focalisant sur les phénomènes complexes. Etant donné le nombre et la diversité des objets à gérer, le nombre d’interdépendances entre ces objets, et le contexte dynamique, incertain et contraignant du projet, il n’est pas étonnant que cela devienne difficile d’anticiper et donc de gérer avec les outils actuels qui n’ont pas été faits dans ce but. C’est l’objet de la section suivante que de fournir une assistance à la modélisation et à la description des composants d’un tel système complexe.
Un modèle de description de la complexité projet Page 63
3.2. UN MODELE DE DESCRIPTION DE LA COMPLEXITE PROJET
Cette section introduit les spécifications de ce qu’on peut attendre d’un modèle de complexité projet puis dans un deuxième temps présente notre modèle de complexité, qui s’est décliné en plusieurs versions successives jusqu’à l’appelation finale ALO-E (Attributs, Liens, Objets – Evènements) qui peut se décliner en ALO-R (pour Risques comme cas particulier d’évènements). Ce travail a été essentiellement mené dans le cadre de ma thèse et de celle de Ludovic-Alexandre Vidal. Il a fait l’objet d’une publication dans Kybernetes : the journal of cybernetics and management science (section 9.1, page 145 et suivantes) et est présent dans d’autres publications, car il pose les données manipulées ensuite. Presque toutes nos applications sont basées sur ce modèle, on peut citer plus particulièrement PSA Peugeot-Citroën et Alstom Transport.