Est-ce ainsi que les projets meurent ?
Les projets informatiques connaissent un taux d’insuccès très élevé. Cet article met en évidence les contraintes et les visions des principaux acteurs et leur impact sur des situations de crise. Cette analyse éclaire des paradoxes apparents et dégage des pistes de réflexion, au-delà des préconisations déjà largement documentées.
L’affaire du Soukoï 24 a tenté de montrer les risques associés aux situations à forte incertitude où les stratégies des acteurs ne sont pas facilement prévisibles et les facteurs de décisions multiples.
Qu’en est-il des situations a priori moins complexes où le jeu des acteurs serait potentiellement prévisible car largement documenté et où l’enchaînement des actions possibles répondrait à un schéma programmatique connu et partagé ?
Ce cas de figure presque idéal devrait conduire à un équilibre qui sans être nécessairement une situation « gagnant – gagnant » devrait satisfaire toutes les parties.
Les projets informatiques relèvent de cette définition. Le nombre des acteurs est défini et leur rôle codifié dans des méthodes et des bonnes pratiques qui font l’objet d’un très grand nombre de livres, d’articles et de formations. L’enchaînement des tâches du cadrage initial à la phase de maintenance applicative et évolutive est globalement la même d’un projet à l’autre. Enfin, il n’est pas rare qu’une même organisation réalise plusieurs projets de transformation SI successifs, avec les mêmes partenaires ou un ensemble restreint de partenaires.
Or les projets informatiques connaissent un taux d’échec ou d’insuccès très important qui ne se dément pas d’année en année, même si la tendance perçue est à l’amélioration.
Cet article va mettre en évidence, en s’inspirant des principes de la théorie des jeux et de l’analyse des risques, les différences de contraintes et de vision des acteurs qui peuvent conduire le cas échéant à l’échec ou à des situations sous optimales.
Cette analyse éclaire quelques paradoxes apparents et dégage des pistes de réflexion pour optimiser le taux de réussite des projets, au-delà des préconisations déjà largement documentées.
Et leurs échecs au loin demeurent
L’analyse des causes de l’échec des projets informatique est une source inépuisable d’études. Si la définition de l’échec d’un projet et la méthode de comptabilisation ne font pas l’unanimité, les statistiques établies par le Standish Group depuis 1994, sont les plus consensuelles. Elles montrent (graphique issu du site d’Alain Battandier) que la part des projets pleinement réussis, si elle s’accroit avec le temps, demeure dramatiquement faible, (moins de 40%) au regard des coûts directs et indirects engagés et des conséquences de l’insuccès.
La littérature spécialisée a exploré les causes de l’échec et dégagé des facteurs clés de succès :
La complexité des projets qui tient à l’inadéquation ou à la surévaluation de l’ambition initiale et de ses conséquences futures au regard des caractéristiques réelles de l’environnement, en termes de capacités collectives, de compétences, de ressources, d’organisation.
Le besoin fonctionnel mal cerné où qui ne se retrouve que très imparfaitement dans les développements techniques opérés.
L’estimation des ressources à mobiliser en décalage avec les moyens réels et les contraintes des organisations et processus existants.
L’organisation du projet tant dans ses dimensions opérationnelles que décisionnelles. Le mode projet, plus ou moins bien appliqué, se surajoutant à des organisations de travail souvent complexes.
L’accompagnement du changement et la participation des fonctionnels mal calibrés ou trop tardifs.
Au regard de l’abondance de la littérature sur le sujet et la richesse des formations à la conduite du projet, il est intéressant de pointer deux paradoxes :
La généralisation des démarches projets et la professionnalisation des organisations clientes n’a pas significativement réduit le risque de survenue des mêmes causes qui entraînent les mêmes effets.
L’écrasante majorité, si ce n’est la totalité des projets en insuccès, ont suivi des « bonnes pratiques » et eu recours à des consultants rompus à celles-ci et bardés de certificat de démarche Qualité.
Ces deux paradoxes entraînent deux questions qui vont constituer le fil conducteur de l’analyse :
Pourquoi l’apport de compétence et la généralisation des bonnes pratiques n’ont-elles pas bénéficié au client à la hauteur du niveau d’excellence revendiqué par les sociétés partenaires ou formatrices ?
Pourquoi des projets dont l’échec potentiel est patent depuis le début sont arrêtés seulement avant le déploiement, sans que les expertises des phases précédentes n’aient stoppé cette dépense d’énergie et de moyens ?
Nous allons analyser les caractéristiques d’un projet SI et les contraintes fortes des différents acteurs. Ces contraintes fortes vont déterminer des tendances lourdes qui vont conditionner les actions et les décisions des acteurs.
Cette analyse va permettre de mettre en évidence des situations critiques où les choix opérés par les uns ou les autres acteurs conduisent à un résultat sous optimal.
Si les raisons de l’échec peuvent être multiples, il ressort des analyses produites sur le sujet que le client, son organisation, ses méthodes, sa capacité d’intégrer la complexité du projet dans son ensemble et sa durée constituent souvent le point névralgique du projet.
Il est intéressant toutefois de noter que les analyses des échecs (ou des réussites) des projets proviennent essentiellement de sociétés de conseil ou de consultants, eux-mêmes parties prenantes du résultat des projets. Ces analyses, par leur focus sur le client, présentent un angle mort. Elles négligent les conséquences de l’interaction des représentations et des finalités de chacun des acteurs.
Pour illustrer ce point, nous allons restreindre le champ de l’étude aux dimensions fonctionnelle et organisationnelle des projets, les ressorts purement techniques nécessiteraient un article à part entière.
Le projet : un jeu dynamique à plusieurs joueurs
L’accélération du rythme des affaires conduit à une perception de la temporalité qui nous distingue des sociétés précédentes. Les années sont désormais du temps long. Les projets SI sont majoritairement inclus dans cette temporalité. En effet, entre la phase de cadrage et la mise en production effective de la solution, complétement accompagnée, plusieurs années se sont écoulées. Une correcte prise en compte de cette dynamique temporelle, la compréhension des contraintes et stratégies des acteurs qui interviennent sur cette période sont donc des éléments essentiels à considérer. Tout acteur qui intégrerait mal cette dimension se met dans une situation dissymétrique qui peut conduire à une sous efficacité des choix et menacer la bonne réalisation des opérations.
Nous allons ici considérer le déploiement d’un projet de système d’information comme un jeu à plusieurs étapes qui se déroulent sur plusieurs années.
Nous allons montrer que le client et son (ou ses) prestataires n’ont pas la même approche de la temporalité du projet ni les mêmes espaces de contraintes. Ces espaces de contraintes sont fondamentaux, ils déterminent des tendances lourdes qui conditionnent très fortement les décisions ou les actions prises par les acteurs du projet.
Les acteurs et les organisations du projet : un mimétisme des formes mais des contraintes différentes
De nombreux acteurs interviennent dans la réalisation d’un projet, une analyse exhaustive de l’ensemble de leurs stratégies et interactions est très difficile et dispendieux.
Nous allons donc nous concentrer sur les dimensions organisationnelle et fonctionnelle en nous focalisant sur trois macro joueurs : le client, l’AMOA et le MOE.
Ces trois macro joueurs regroupent en leur sein une multiplicité d’acteurs dont les actions et les décisions sont importantes. Chaque macro joueur est ici vu comme le sur ensemble des acteurs qu’il représente. Nous allons centrer l’analyse sur l’acteur le plus symbolique pour chaque entité, le chef de projet (noté CP par la suite).
Les organisations projets des clients et des prestataires présentent généralement un mimétisme des formes qui s’articule autour du rôle clé du CP. La description des activités et compétences clés d’un CP a fait l’objet d’un grand nombre d’articles. Elle ne sera pas reprise ici.
Par contre, les différences fondamentales entre les CP client et prestataire, leurs environnements réels de travail et leurs conséquences sur les décisions ou les choix qu’ils peuvent être amenés à prendre sont très importants à souligner.
Le CP client est généralement un expert fonctionnel légitime aux yeux de sa communauté, du fait de son expertise ou de sa position dans l’organisation. Hormis au sein des DSI, il est rare que la fonction de chef de projet soit positionnée comme un métier inscrit dans une filière professionnelle à part entière. En conséquence, cette fonction, pour celui qui l’incarne, est transitoire, elle ne constitue qu’une étape d’une carrière et non le cadre professionnel de référence.
Le CP client est également tributaire des processus fonctionnels que le projet vise à instrumenter ou optimiser. Ces processus ont une temporalité, un rythme, des exigences différents de ceux du projet. Même si la dimension prospective et pluriannuelle est continuellement mise en avant, les processus de gestion sont marqués dans la réalité par une temporalité nettement plus courte, au mieux annuelle. De plus, cette temporalité n’est pas identique d’un processus à l’autre. Dans le cas d’un projet complexe couvrant plusieurs processus, régis par plusieurs services ou organisations, la somme des contraintes issues des processus opérationnels devient très difficile à intégrer pour un CP.
Dans la vie quotidienne d’un projet, il est très fréquent que ces contraintes interfèrent très fortement avec la vie du projet, conduisant, par exemple, au report de réunions de travail ou à l’impossibilité de valider dans le temps prévu ou dans la profondeur souhaitée les livrables attendus. Ces perturbations sont d’autant plus importantes dans un monde où les contraintes budgétaires ou financières restreignent les ressources disponibles et accroissent la compétition d’allocation entre processus opérationnels et projet.
En conséquence, le CP client va devoir concilier deux ensembles d’exigences, celui propre au projet et celui relatif à l’organisation et aux processus fonctionnels. Ces deux ensembles ne sont pas régis par les mêmes règles et la même importance. En cas de conflit, le second l’emporte très souvent sur le premier. Cela peut porter sur les ressources mises à disposition par exemple ou sur des arbitrages qui ne sont pas toujours optimaux au regard du projet uniquement mais qui prennent tout leur sens dans le contexte de l’organisation cliente, de ses finalités, de ses processus.
Cela est normal et légitime. Le projet ne constitue qu’un moyen transitoire de réaliser une activité dont l’organisation et les processus fonctionnels sont les colonnes vertébrales de réalisation. En d’autres mots, la gestion de projet n’est généralement pas l’ADN consubstantielle de la société cliente. Cela constitue une différence fondamentale avec l’approche et les stratégies d’une société de conseil.
La gestion de projet est l’essence même de ces sociétés. Elle en constitue le cœur de métier et le cadre de référence. En conséquence, une société de conseil en SI, surtout celle qui fait à la fois de l’AMOA et de l’intégration, pense le temps long du projet et même la phase qui suit immédiatement, la maintenance corrective et évolutive.
Ceci entraîne évidemment une posture et un cadre de réflexion et d’action différents pour le CP prestataire. Je vais m’appuyer ici sur l’analyse développée par Patrick Razafimamonjy dans son mémoire du CNAM consacré aux bonnes pratiques des projets.
Le CP prestataire s’inscrit dans une filière métier et un environnement dont le mode projet constitue une référence permanente. La gestion de projet n’est pas une activité accessoire ou transitoire, elle est l’essence même de ces sociétés.
En plus des exigences du projet formalisées par les engagements contractuels et les bonnes pratiques de référence, le CP prestataire doit respecter les objectifs de rentabilités fixés par sa Direction Générale. Ceux-ci sont conditionnés par les conditions de vente signées lors du contrat. Or le CP prestataire intervient généralement peu dans la phase contractuelle. Souvent, il est même nommé une fois la phase de vente terminée.
Dès lors, il doit concilier les hypothèses retenues par le service commercial, qui répondent d’une logique concurrentielle de différentiation par les prix et la qualité, aux exigences de rentabilité de sa direction et à la réalité opérationnelle. Ces hypothèses, construites sur la base d’abaques standards, en situation d’informations incomplètes, traduisent une réalité idéale ou optimale qui peut être en grand décalage avec la situation réelle. La méthode même de construction des coûts estimés entraîne ce décalage. Cette estimation s’appuie généralement sur des coûts jugés certains (les coûts de développement d’une ligne de code par exemple) pour évaluer l’incertain via des facteurs multiplicateurs issus de projet jugés comme réussis.
De plus, la tension concurrentielle conduit les sociétés à proposer des devis les moins chers possibles ce qui va accroître la pression qui pèse sur le CP prestataire pour concilier les exigences du projet et la rentabilité de la prestation.
Le CP prestataire doit également composer avec son organisation pour constituer son équipe. Il est ainsi directement en compétition avec les autres projets dans lesquels intervient sa société.
Enfin, il est tenu d’appliquer un ensemble de normes procédurales qui constitue le référentiel Qualité de sa société ou le processus de reporting. C’est sur cet ensemble que repose l’industrialisation des méthodes de production des sociétés de service.
Le CP prestataire est donc confronté au paradoxe de devoir satisfaire le cas spécifique d’un projet particulier avec des méthodes génériques.
Dans la vie d’un projet, il n’est pas rare que les deux ensembles d’exigences et de contraintes qui pèsent sur le CP prestataire (celui du projet et la rentabilité de la prestation ou la logique d’entreprise) entrent en conflit.
Le choix qui sera privilégié par la société de conseil dépend pour partie de l’espérance de gain que la société espère retirer du projet et de ses suites éventuelles.
Des phases aux enjeux et stratégies différents
La vie d’un projet peut être synthétisée en trois grandes phases : celles de la conception (du cadrage à la rédaction du cahier des charges), de la spécification qui décrit dans le détail fonctionnel puis technique les attendus de la solution et enfin celle de la réalisation de la solution et de la préparation au déploiement.
Le jalonnement retenu peut être différent d’un projet à l’autre mais une certitude demeure : une distinction très importante est opérée entre ces phases et celle de maintenance et d’exploitation. Ces dernières, post déploiement, sont considérées comme hors projet, régies par des modes de production et des contrats particuliers (de TMA par exemple) essentiellement pilotés par la DSI.
Pourtant cette phase de TMA n’est que la continuité logique des phases précédentes et sa perspective et les enjeux notamment financiers associés ne sont pas neutres pour l’économie générale de la solution mais peut également avoir une incidence sur la réalisation du projet.
Financièrement, la maintenance constitue une source non négligeable de revenu pour les sociétés de conseil, le ratio ressources investies/ revenus étant très nettement supérieur à celui des phases précédentes et notamment celle de l’intégration.
La vie d’un projet est rythmée par des procédures contractuelles, pilotées par le client qui vise à sélectionner les partenaires du projet. Ces procédures sont généralement organisées par phases et peuvent être exclusives. Ainsi la société d’AMOA retenue pour la phase de cadrage de production du cahier des charges ne peut pas être l’intégrateur de la solution dans les phases suivantes.
Une société prestataire doit donc faire le choix de son positionnement. Il est fréquent que la société qui intègre la solution exerce au moins dans un premier temps la maintenance applicative et évolutive après le déploiement. Cette maintenance est constituée souvent d’un lot forfaitaire visant à traiter les anomalies, c’est-à-dire les écarts aux spécifications, et d’un lot à la demande pour gérer les demandes d’évolutions. Pour des sociétés qui, contrairement au client, intègrent toutes les phases du projet dans leur stratégie, cette perspective n’est pas neutre et influence les actions lors des phases antérieures.
Nous allons donc considérer les phases du projet et regarder, au regard des tendances lourdes décrites précédemment, quelles peuvent être les stratégies des acteurs en cas de difficultés et leurs conséquences pour le projet.
La phase de conception
Une des causes des échecs souvent répertoriée est une formalisation du besoin imprécise ou trop éloignée de la réalité. Le cahier des charges n’est alors qu’un document de cadrage un peu étoffé, le véritable besoin devant être étudié en spécification. Un écart considérable peut alors apparaître entre les estimations initiales (coûts, délais et charges) et la réalité. Ceci, dans le cas des contrats au forfait notamment, ne manque pas de générer une crise au sein du projet. Le cahier des charges représente l’engagement à réaliser pour la société de service mais également pour le CP client. Toute révision de cette base contractuelle entraîne des avenants.
Au-delà des cas extrêmes qui relèvent d’un manque de compétence, d’analyse ou de préparation, cette première crise potentielle peut être le reflet des tendances lourdes décrites précédemment.
Un cahier des charges décrit une réalité future qui ne sera déployée dans sa complétude que plusieurs années après sa description initiale, même si des premières fonctionnalités ou des fonctionnalités intermédiaires peuvent être déployées en avance de phase, selon le principe des Quick Win. Afin d’éviter l’effet tunnel et de limiter les coûts, la rédaction du cahier des charges est généralement réalisée en quelques mois. Ce délai peut être variable mais il n’est que très rarement proportionnel à la complexité des projets. Les contraintes externes ou des nécessités internes poussent en effet à la réduction de ce délai.
Les espaces de contraintes qui pèsent sur le CP client et le CP prestataire vont alors jouer à plein dans le cas des projets complexes, accroissant le risque de cette phase et les probabilités d’échec final. La profondeur et la qualité d’un cahier des charges est la résultante de la mobilisation des fonctionnels, c’est-à-dire de l’arbitrage implicite ou explicite rendu par la DG cliente pour l’allocation des ressources entre les processus opérationnels et le projet. Or plus les processus et services impliqués sont nombreux, plus l’arbitrage devient implicite c’est-à-dire rendu de fait par les responsables des services dont dépendent les experts, qui privilégient le plus souvent le bon fonctionnement de leurs processus opérationnels dont dépend celui de leurs services. Tous les plans de charges établis, même avec la plus grande rigueur méthodologique, se heurtent à cette contrainte.
Le CP client ne peut pas compenser l’absence de ses fonctionnels par une sur mobilisation du CP prestataire. Outre que ses équipes n’ont pas la légitimité fonctionnelle, celui-ci est contraint par l’exigence de rentabilité de sa DG et les limites de l’engagement de ressources proposées dans l’offre. Même si celle-ci n’a qu’une valeur contractuelle secondaire par rapport au CCTP et que l’engagement est au forfait, le CP prestataire ne peut aller au-delà des limites fixées par sa société.
Chaque organisation à un seuil de complexité au-delà duquel les tendances lourdes décrites ci-dessus vont générer un risque majeur. Plus la complexité s’accroit, plus la tentation de lotir le projet grandit et avec elle le risque que les effets externes d’une spécification sur l’autre soient mal pris en compte.
Chacun a sans doute en mémoire quelques exemples fameux de projets échoués à l’ambition d’autant plus titanesque qu’elle reposait sur la mobilisation d’un nombre conséquent de fonctionnels venus de services ou d’entités différentes pour formaliser des processus eux-mêmes très complexes et divers.
L’expertise et l’expérience collective devraient conduire à l’estimation de ce seuil et à l’arrêt ou à la redéfinition des projets qui le dépasse, dès ce premier stade. Il est certain qu’un grand nombre de projets en échec ou dont le ROI n’est pas à la hauteur des espérances initiales ont dépassé ce stade sans que les mesures correctives associées aux risques ne soient prises à temps.
Les tendances lourdes ont conduit dans ces cas-là à une décision sous-optimale, celle de poursuivre le projet, alors même que sa viabilité était dès le départ fortement compromise. Il apparaît donc essentiel que le CP Client avec l’aide du CP AMOIA fixe le seuil (un ensemble minimal de conditions) au-delà duquel, il est nécessaire de stopper ou de reconfigurer le projet. Ce seuil ne doit pas être fixé uniquement à l’aide des bonnes pratiques, mais d’une connaissance précise de la réalité des mécanismes d’action et de décision de la société cliente, en un mot de sa sociologie des comportements.
La phase de spécification
Les phases de conception générale et détaillée sont le théâtre d’un jeu de rôle entre les CP Métier, AMOA et MOE autour de l’implicite ou de l’explicite des besoins formulés dans la phase précédente. Ce jeu peut également porter, pour les solutions instrumentées par des ERP, sur la part des fonctionnalités standards (et donc du spécifique) dans la solution délivrée.
Le CP MOE prestataire vise généralement à faire le plus simple (et le plus économique), c’est-à-dire appliquer les méthodes robustes en réduisant le champ des demandes à une solution instrumentable, connue et maîtrisée. Cette tactique est parfaitement illustrée par le conseil donné par un chef de projet sur son blog.
Non pas qu’il faille répondre « NON » à toutes les demandes, qu’elles soient implicite ou non au cahier des charges – Là n’est pas la question -. Mais plutôt d’atteindre le même résultat par un chemin plus simple ou bien de démontrer que la fonction demandée n’est pas réellement utile. Souvenez-vous, les solutions les plus simples sont toujours les meilleures. Votre rôle sera surtout de vous assurer que ce qui a été vendu (voir sous-vendu) est finalement réalisable. Gardez en mémoire que seulement 45% des fonctionnalités demandées sont réellement utilisées.
(Source : https://gestiondeprojets.wordpress.com/2008/06/24/gestion-de-projet-etape-2-les-specifications/)
De leur côté, les fonctionnels souhaitent bien souvent reproduire, en minimisant les défauts et les limites, les solutions qu’ils connaissent et maîtrisent.
Les CP client doit intégrer ce souhait en le combinant avec son objectif propre, s’assurer de la conformité de ce qui va être développé au regard des besoins du CCTP. Dans le même temps il est contraint par les jalons de validation du projet.
Si la maintenance de l’application déployée est une perspective réaliste pour sa société, le CP MOE prestataire a également intérêt à ce que la solution soit correctement déployée et que le champ des fonctionnalités spécifiées soit restreint au maximum, afin que celui des futures évolutions soit le plus étendu possible.
Malheureusement, peu de CP client intègrent dans leur réflexion cette dimension stratégique, sa temporalité étant limitée par le déploiement qui généralement marque la fin de son engagement dans le projet.
Nous avons ici une différence de vision stratégique et de perception du temps qui peut avoir un impact important sur l’économie générale de la solution déployée.
Le risque survient dans cette phase, lorsque les tendances naturelles des CP deviennent difficilement compatibles. Le risque porte alors sur la dérive des délais et des coûts sans accord entre le client et le fournisseur. Mais également sur la validation totale ou avec réserve, au forceps, de spécifications dont les écarts avec le besoin initial sont mal compris ou dont les conséquences sont mal appréhendées.
C’est ici que l’effet psychologique de l’engagement (le fait de poursuivre ou de reproduire une action même mal engagée) joue à plein, d’autant plus si les spécifications ont conduit à un surcoût et un dépassement des délais.
Le CP client doit avoir dès le départ une stratégie claire de réalisation qui porte également sur l’exploitation de la solution au-delà du déploiement. Pour répondre à un besoin, le client peut décider de s’appuyer sur le standard de la solution préconisée techniquement (par exemple un ERP) et d’étudier les spécifiques au regard de la faisabilité ou des coûts d’adaptation des processus métiers. Il peut a contrario privilégier uniquement les besoins métiers quitte à multiplier les spécifiques pour faciliter l’appropriation des utilisateurs. Ces deux approches n’auront pas du tout la même incidence sur le développement du projet et sur ses suites.
Le CP AMOA doit jouer également un rôle essentiel. De par sa posture en appui des fonctionnels et sa maîtrise des modalités d’actions des sociétés de conseil, il doit aider le client à la définition de ce qui est acceptable et définir les limites à ne pas franchir dans l’engagement.
La phase de réalisation
Dans cette phase finale, le fonctionnel est tenu éloigné de la réalisation unitaire et ne reprend la main que pour préparer le déploiement, c’est à dire concrètement la recette fonctionnelle et l’accompagnement au changement. Il existe évidemment de grands risques sur ces deux phases que les bonnes pratiques visent à juguler.
Cette phase est également le moment ou le CP client MOE prend le lead de l’action devant le CP métier, du moins avant la recette fonctionnelle. Même si le client ne parle que d’une seule voix, il est important de prendre en compte les différences de représentation qui peuvent exister entre ces deux acteurs, leur culture, leur approche étant différentes.
Dans certains projets complexes, les deux équipes métiers et techniques sont physiquement séparées, et il est parfois compliqué pour les intervenants de bien saisir la répartition des responsabilités entre celles-ci.
Quelques pistes pour conclure
Pour réduire le taux d’échec, la tendance principale a consisté à généraliser les bonnes pratiques et les méthodes de conduite de projets, surtout celles souples et réactives. La réduction du taux d’échec doit sans aucun doute être mise au crédit de cette politique de formation et de mutualisation des bonnes pratiques qui permet d’éviter les erreurs les plus flagrantes.
Toutefois, une voie uniquement focalisée sur la méthode qui n’intégrerait pas le contexte d’actions des acteurs a peu de chance de réduire significativement le taux d’échec.
Elle peut même, par excès de formalisme, ajouter un niveau de complexité à des activités déjà passablement compliquées et accroître ainsi, paradoxalement, les risques. Il est frappant par exemple de constater combien l’accroissement du formalisme et des processus de qualité et de reporting (tous obligatoires de fait) a réduit le temps disponible des CP pour l’exercice de leurs responsabilités premières.
Cela peut conduire par exemple à mal estimer ou qualifier des risques. Une mobilisation insuffisante des fonctionnels est vue comme un risque majeur et un facteur élevé d’échec. Pourtant, la rareté de l’expertise mobilisable au moment idéalement voulu, n’est pas un risque, mais une contrainte propre à la logique des processus et des organisations. Le CP doit donc intégrer cette contrainte pour présenter un plan de charges qui intègre la réalité.
Il est essentiel également que les CP client intègrent dans la gestion projet tous les temps du projet y compris celui de la maintenance. Il est des projets qui sont considérés comme réussis lors de leur déploiement (respect des délais et des coûts, fonctionnalités déployées proches des spécifications etc.) mais qui se révèlent par la suite des gouffres financiers au cours de l’exploitation.
En résumé, pour réduire les risques d’insuccès, il apparait essentiel que :
chaque acteur majeur du projet, et en particulier les CP, partage une bonne compréhension des contraintes structurantes qui déterminent son action et celles de ces partenaires. Cette culture de l’autre, de son mode de fonctionnement et donc de décisions n’est pas suffisament partagée à ce jour ;
Le CP avec l’appui du CP AMOA ait une stratégie de développement de son application, qui ne soit pas limitée au temps du projet, mais à l’espérance de vie et d’évolution de la solution ;
Les limites de l’engagement soient fixées pour chaque phase, non pas sur la base de bonnes pratiques génériques mais en intégrant la réalité sociologique de fonctionnement des organisations et des processus clients et projets ;
Le formalisme associé au projet soit limité au maximum pour laisser le temps et l’énergie aux CP de piloter réellement le projet.
Ce tableau propose, en synthèse, des préconisations complémentaires aux bonnes pratiques.
Sources
http://alain.battandier.free.fr/spip.php?article55
http://www.journaldunet.com/solutions/expert/50420/projets-informatiques-sans-gouvernance-ni-conduite-du-changement---le-deraillement-assure.shtml
http://www.journaldunet.com/solutions/expert/50420/projets-informatiques-sans-gouvernance-ni-conduite-du-changement---le-deraillement-assure.shtml
http://www.larevuedudigital.com/2014/07/07/les-3-raisons-dechec-des-projets-informatiques-du-secteur-public/
http://www.finyear.com/Echec-des-projets-informatiques-4-causes-majeures_a12238.html
http://www.my-project-cafe.com/echec-projets-informatiques-echec-demarche-gestion-projets
http://www.finyear.com/Echec-des-projets-informatiques-4-causes-majeures_a12238.html
http://blog.sodifrance.fr/it-success-failure-story-check-point-2014/
https://books.google.fr/books?id=vmLVD4OuK-oC&pg=PA19&lpg=PA19&dq=projet+informatique+r%C3%A9ussite+%C3%A9chec&source=bl&ots=pssG769bAo&sig=eUERxFYAl734B3cpfLBBC96O7lU&hl=fr&sa=X&ved=0ahUKEwiy_MWzt7XJAhWDWRoKHZtsBt8Q6AEIXTAL#v=onepage&q=projet%20informatique%20r%C3%A9ussite%20%C3%A9chec&f=false
Mémoire Diplôme Master ATDC « bonnes pratiques chercher l’erreur », Patrick RAZAFIMAMONJY, 10 juillet 2015.
