Note : ce texte a été rédigé pour un client de l'Agence Rédaction Web, il figure ici uniquement à titre d'illustration, afin de vous permettre d'imaginer la qualité rédactionnelle que nous fournissons. Le texte ci-dessous a été rédigé voici plus de 24 mois, il n'est plus d'actualité et peut comporter des éléments et des chiffres hors contexte qui nuiraient à la compréhension.
L'étude CHAOS du Standish Group, une cabinet de consulting basé à Boston, indique régulièrement depuis quinze ans les causes principales d'échec dans les projets informatiques. Dans sa version 2009 publiée en mai dernier à partir des réponses de 400 entreprises, il apparaît qu'à peine un tiers (32%) des projets sont terminés dans les temps, avec les fonctions requises et dans le budget préétabli. Une petite moitié des projets se termine dans la douleur : en retard, souffrant d'un dépassement de budget, ou avec des fonctionnalités manquantes – bien que le Standish souligne qu'un dépassement de budget puisse avoir des conséquences positives, si le système apporte des fonctionnalités supplémentaires utiles. Enfin, un quart (24%) des projets meurt tout simplement, soit parce qu'ils sont annulés avant la fin, ou pire parce qu'ils sont livrés mais jamais utilisés. La part des échecs est en augmentation, atteignant un plus haut depuis dix ans : dans le dernier opus datant de 2006, les parts étaient de 35% pour les succès, 19 % pour les échecs et 46 % pour les accouchements difficiles. Selon Jim Johnson, du Standish Group, c'est la crise qui est responsable. « En des temps difficile, on est beaucoup plus enclin à annuler un projet qui se passe mal. Cela concerne 20 à 25 % des annulations.» estime-t-il. Outre ces raisons conjoncturelles, la cause principale de ces échecs tient en une seule ligne selon lui : les besoins précis n'avaient pas été correctement compris et pris en compte durant la phase initiale du process.
Les exemples sont parlants : en 2005, le géant britannique de la distribution Sainsbury a passé 526 millions de dollars en pertes, pour cause de système de gestion de la supply chain défaillant. Selon Jim Johnson, « si votre ERP coûte plus de 10 millions de dollars, les chances de succès sont statistiquement de zéro ». Toujours en Angleterre, un projet public de gestion des prisons, intitulé C-NOMIS, démarré en juin 2004, a été abandonné en juillet 2007 après avoir dépassé le délai imparti de deux ans, et atteint la somme faramineuse de 155 millions de livres sterling. Le patron du Public Account Committee, la Cour des Comptes anglaise, a indiqué au micro de la BBC que « les erreurs dans la gestion de ce projet étaient dignes du jardin d'enfant ».
Les erreurs relevées sont symptomatiques d'un projet mal mené. En premier lieu, un management de projet médiocre, tant sur la planification que sur le suivi financier. Les estimations de temps et de coût furent extrêmement optimistes, et la complexité du projet a été sous-estimée. Le contrôle des coûts s'est fait par rapport au budget et non par rapport aux livrables. Le contrôle des modifications était quasi inexistant. En outre, le contrôle et le suivi des fournisseurs était laxiste. Guère étonnant dans ces conditions de voir le projet capoter !
Un des moyens d'éviter les problèmes consiste à employer un système de gestion de projet « Agile » qui permet d'avancer par petites étapes, validées au fur et à mesure, plutôt que de passer des mois à avancer sur le projet afin de montrer une version complète au client. En cas de pépin, la rectification est bien plus rapide dans le premier cas. Et le système permet de valider les choix. Un besoin que le client estimait fondamental peut, après validation, se révéler peu important et passer en queue de peloton dans la liste des tâches.
Sany Maamari est le responsable du développement de COGENIT, SSII parisienne d'une quinzaine de personnes, spécialisée dans la spécification et la validation, qui conçoit également des outils open source. Sa particularité est de travailler directement avec des grands comptes comme France Télécom ou la Banque Postale; contrairement à d'autres entreprises de taille similaire qui sont forcée de passer par des SSII plus grandes pour entrer sur les grands marchés. Cette spécificité s'explique, selon M. Maamari, par le marché de niche choisi par COGENIT, celui des solutions innovantes pour la gestion des spécifications. « Nous proposons une spécificité méthodologique basée sur des outils que tout le monde connaît – les 13 diagrammes UML- mais qui sont souvent mal utilisés : il faut les imbriquer entre eux pour parvenir à un résultat cohérent ».
Et de citer un proverbe de codeur : « plus tôt on commence le développement, plus tard on le finit. ». Selon lui, le fournisseur doit savoir faire preuve de fermeté, son expertise projet est en jeu : « lorsqu'un client manque de maturité projet, la SSII doit le lui signifier, c'est son rôle dans l'intérêt de tous ». Car les SSII ne sont pas toujours responsables des problèmes : « certains clients pensent qu'établir un cahier des charges imprécis leur permettra de rajouter discrètement des lignes par la suite, or c'est exactement ce qui assassine un projet ». La maîtrise d'ouvrage doit donc chercher à éliminer au maximum les imprécisions initiales, ce qui permettra à la maîtrise d'œuvre de dresser des spécifications fonctionnelles claires qui seront aisément validées. Et lorsqu'il s'agit d'une intégration avec une relation triangulaire éditeur/intégrateur/client, ce dernier doit chercher à disposer d'un seul interlocuteur, sorte de guichet unique, car s'il se transforme en coordinateur l'échec est en vue. Chacun ses compétences.
1- Impliquer les utilisateurs, et en cours de projet garantir la communication entre tous les acteurs.
2- S'assurer du soutien de la direction, impliquer le management de haut niveau.
3- Déterminer des objectifs clairs, et s'assurer du lien entre les priorités stratégiques de l'entreprise et celles du projet
4- Bien dimensionner le projet.
5- Utiliser un processus Agile qui permet de découper le projet en sous-unités moins complexes, dont on peut embrasser l'étendue plus aisément.
6- S'assurer de l'expertise et de l'expérience du chef de projet.
7- Conserver à l'esprit la gestion financière du projet et les retours attendus. Ainsi, on évitera de sélectionner le fournisseur selon des critères de prix uniquement plutôt que selon les bénéfices attendus à terme.
8- Allouer des ressources de bon niveau.
9- Proposer une méthodologie formelle.
10- Utiliser des outils et une infrastructure standard.
Please add your bio info through your member profile page, or through your dashboard.