performance de grands projets TI

Javascript is currently disabled. This site requires Javascript to function correctly. Please enable Javascript in your browser!

RSM Blog - Articles, nouvelles, commentaires

Performance de grands projets en TI

Posted on 24/08/2013 by SuperUser Account in grands projets informatiques performance projets TI facteurs de succès de projets mégaprojets TI
image

On sait que, pour réussir un grand projet, çà prend de l'expérience. Or, on dit parfois que l'expérience est constituée de la somme de nos erreurs. On sait aussi qu'il est permis d'apprendre des erreurs des autres! Est-ce que cela signifie que même dans l'insuccès on peut trouver quelque chose de bénéfique? Sans doute, si l'on procède à un bilan complet. Radenko Corovic du RSM Technologies est un acteur dans la mise en oeuvre des bonnes pratiques de gouvernance des projets et de portefeuilles de projets depuis plusieurs années. Il nous offre sa perspective sur ce qui nuit au succès des grands projets en technologies de l'information.

Pourquoi les grands projets en TI connaissent-ils une si mauvaise performance?

Par Radenko Corovic, B.Sc.A, MBA, RSM Technologies (Article publié dans le Bulletin du PMI-LQ)

Les projets informatiques de grande envergure coûtent souvent plus cher que prévu et connaissent un taux de succès considérablement moins élevé que les petits et moyens projets. Voici des faits démontrés par de nombreuses recherches et dont on peut facilement prendre connaissance en lisant des journaux ou en écoutant la télé. Selon l’étude de McKinsey/Oxford, la moitié des grands projets en TI (avec des budgets de plus de 15 millions de dollars) dépensent 45 % plus que le budget estimé, dépassent les délais de 7 % (33% pour les projets applicatifs) et livrent 56 % moins de fonctionnalités que prévu. Plus le projet est long, plus il court la chance de dépasser le budget ou les délais. Toutefois, 17 % des projets informatiques vont si mal qu'ils peuvent menacer l'existence même de l'entreprise.

Quelques exemples

Pour ne pas aller très loin, on peut citer quelques exemples de chez nous selon le  Rapport du Vérificateur général du Québec, 2010-2011, dont le Dossier santé du Québec (estimé à environ 500 M$ il y a sept ans, les coûts liés au projet s'élèveraient maintenant à près de 1,6 G$), ainsi que le Système intégré d'information de justice-SIIJ (suspendu après avoir dépensé 75 M$), sans compter le Registre canadien des armes à feux (coût initial estimé à 119 M$, révisé graduellement à 1 G$). 

Les entreprises privées ne dévoilent que rarement les échecs de leurs projets, mais voici deux exemples canadiens : 

  • En 2009, après plus de 3 années d'efforts de développement et 67M$ dépensé, Air Canada suspend un projet de gestion de réservations.
  • L’Association canadienne des paiements (ACP) a annulé en 2009 le projet de numérisation des chèques après quelques années de développement. Le montant n’est pas dévoilé, mais les sources proches du projet parlent d’un projet de 300M$.
La situation n’est pas différente ailleurs. En voici trois exemples récents qui viennent d’autres pays: 
  • Le projet d’informatisation des soins de santé au Royaume-Uni, très similaire au projet Dossier santé du Québec, a été annoncé en 2002 au coût autour de 3,5 G£ (autour de 5,6 G$) avec une durée planifiée de trois ans. Le projet a finalement été démantelé en 2011 après avoir dépensé 12 G£. La conclusion a été que le projet ne pouvait pas livrer les résultats planifiés et qu’il fallait le fragmenter (moduler en plus petites unités).
  • Un projet qui  visait à moderniser la gestion du système judiciaire de la Californie a été abandonné en 2012 après avoir dépensé plus de 300 millions de dollars. Le logiciel était viable, mais il aurait fallu 343 millions de dollars de plus pour le mettre en œuvre et le système serait devenu désuet avant même d'être terminé.
  • La US Air Force avait décidé d'abandonner un projet majeur de logiciel ERP («Enterprise Resource Planning») après avoir dépensé 1 G$. Le projet aurait nécessité 1 G$ juste pour compléter un quart de la portée initiale, sans pouvoir être complété avant 2020.

Des facteurs communs aux grands projets en TI

Pourquoi les grands projets informatiques connaissent une si mauvaise performance? Il est certain que la fonction informatique doit prendre une bonne partie de responsabilité pour ces résultats, mais on peut quand même identifier d’autres causes qui sont de nature plus générale et objective et qui, à mon avis, affectent beaucoup plus la performance de grands projets TI que simplement la compétence ou l’efficacité de la fonction informatique.  

1. Des changements dans les exigences

Comme ils s’échelonnent sur une période de temps beaucoup plus longue que les petits projets, les projets de grande envergure courent plus de chance de voir leurs exigences initiales changées. Ces changements sont le plus souvent provoqués par les facteurs liés à l’environnement du projet. Qu’il s’agisse des lois, des règlementations ou encore des besoins du client qui ont évolué dans le temps, ces changements survenus au cours de la réalisation du projet bousculent les prémisses de base du projet et amènent inévitablement aux dépassements des délais ou des coûts.

L’autre facteur important, devenu dernièrement très fréquent, est le changement de l’environnement technologique ou organisationnel du client. La solution technologique du projet devient simplement obsolète avec le temps et il faut la modifier ou parfois même complètement la changer. Chacun de nous connaît probablement un projet qui n’est même pas terminé et dont la solution technologique doit être mise à niveau (voir l’exemple du projet de l’état de Californie cité ci-haut). Sachant qu’un changement de la solution qui survient au milieu ou vers la fin du projet coûte considérablement plus cher que s’il avait été effectué dans les premières phases de réalisation, on peut facilement imaginer l’ampleur de son impact sur les coûts et l’échéancier du projet.

2. La complexité intrinsèque des grands projets

Par leur nature, les grands projets sont très complexes. Ils impactent habituellement plusieurs des systèmes existants, englobent souvent les fonctionnalités très hétérogènes et impliquent plusieurs parties prenantes. Tous les projets cités ci-haut visaient à remplacer ou à intégrer des dizaines ou parfois des centaines des systèmes existants. En plus, les grands projets sont souvent vus par l’organisation comme une opportunité de régler des problèmes dans le fonctionnement des systèmes informatiques non liés directement au système à construire. Ces ajouts apportent une complexité additionnelle dans la réalisation du futur système, ce qui se traduit souvent par des dépassements des coûts et des délais.

3. Un taux de roulement excessif

Les projets informatiques sont très sensibles aux fluctuations des membres de l’équipe de projet. À cause des spécificités de projets informatiques, la courbe d’apprentissage des nouveaux membres d’équipe de projet peut être beaucoup plus longue que dans la plupart des autres industries. C'est le cas du départ des personnes clés, susceptible d'entraîner des impacts très négatifs sur la productivité de projet. Comme les mégaprojets demandent un temps de réalisation plus long que la moyenne, ils connaissent habituellement un taux de roulement du personnel beaucoup plus élevé que les petits et moyens projets, ce qui a des effets directs sur la réalisation du projet.

4. Une perte de la motivation dans l’équipe de réalisation

Le facteur humain, qui compte pour environ 80 % des coûts des projets informatiques (développement applicatif/logiciel), constitue le facteur déterminant du succès d’un projet informatique. Compte tenu de la longue durée des grands projets, il est compréhensible qu’il soit très difficile de garder la motivation des membres de l’équipe du projet tout au long d'un projet qui peut s’étirer sur quelques années. Cela entraîne soit le départ des personnes clés, soit une baisse significative de la productivité de l’équipe.

5. L’inefficacité des grandes équipes

Un grand projet nécessite généralement une équipe de grande taille. Cependant, les nombreuses recherches effectuées, de même que quelques exercices d'étalonnage ("benchmarking") que j’ai réalisés, ont conclu que les équipes de plus grande taille (10 personnes et plus) sont beaucoup moins performantes que les petites équipes. Cela est attribuable à plusieurs facteurs, le principal étant la multiplication des flux de communication au sein de l’équipe.

6. Une gouvernance des TI mal préparée pour les grands projets

Une autre cause de ces difficultés concerne la capacité organisationnelle de bien planifier et gérer effacement les grands projets informatiques. Afin de s'attaquer aux grands projets informatiques, l’organisation doit s’assurer de disposer de processus efficaces, des meilleures pratiques en gestion de projets ainsi que de ressources très expérimentées. Cependant, les organisations informatiques bien préparées pour ce genre de projets, qui demande un haut niveau d’efficacité, ne sont pas trop répandues. Selon une enquête de Gartner (Gartner Executive Programs CIO Survey), les organisations hautement efficaces en technologies de l’information ne représentent qu’un huitième de toutes les organisations informatiques.

7. L’influence de l’approche méthodologique

Comme tout autre projet, la réalisation de grands projets implique l’utilisation d’une approche méthodologique qui permet de découper un projet en étapes «significatives». La méthode séquentielle de développement «en cascade» (l'approche encore la plus utilisée en développement informatique) implique que les spécifications pour la solution complète soient déterminées au début du projet. Les projets qui ont du succès auront tendance à appliquer la méthodologie qui est flexible et qui permet d’ajuster les spécifications du projet en cours de son exécution pour s'adapter aux besoins changeants des clients.

Alors pourquoi des mégaprojets ?

Tous ces éléments mentionnés ne sont pas nouveaux et ils sont plutôt connus dans la théorie, ainsi que dans la pratique de gestion de projets. Alors pourquoi, malgré tout ce qu’on sait, démarre-t-on encore des mégaprojets informatiques?

À ce qu’il me semble, la première cause de ce constat est liée au fait que la phase de définition de la solution d’affaires, celle où l’on décide ce que le futur système devrait faire et ce qui est déterminant pour l’envergure du projet, est souvent réalisée dans le milieu d’affaires et sans la participation des équipes des TI. De cette façon on définit la future solution, souvent trop lourde et trop complexe, sans trop se soucier de la façon dont cette solution sera réalisée et mise en place.

La deuxième cause concerne les facteurs politiques. Les décideurs sont assez enclins à annoncer des mégaprojets parce que, politiquement, cela cadre bien avec les grandes annonces et la forte médiatisation qui l'accompagne. D’un autre côté, à cause de la durée prolongée des grands projets, les politiciens qui en font l’annonce ne seront probablement plus dans la même fonction quand le projet va éventuellement connaître des difficultés. Ils ne courent donc pas beaucoup de risques de subir les conséquences si le projet échoue.  

Enfin, malgré des nombreuses recherches et études, il semble qu’une bonne part des décideurs et même des praticiens ne sont pas encore convaincus que les grands projets coûtent plus cher et qu’ils sont beaucoup plus risqués que les projets de petite taille. En informatique, les yeux sont souvent plus grands que la panse. Il reste donc un travail important de sensibilisation à faire auprès de la communauté informatique afin qu’elle adopte une approche différente dans la gestion de grands projets.

Il est intéressant de noter que les mégaprojets se retrouvent plus fréquemment dans le milieu public que dans le secteur privé. Étant plus sensibles aux coûts de projets que les organisations publiques, les entreprises ont pris, il y a quelques années, un virage vers les projets de plus courte durée. Les organisations publiques, sous la pression des médias et face aux budgets limités, commencent elles aussi à revoir leurs pratiques de gestion de projets. La nouvelle politique-cadre du Gouvernement du Québec sur la gouvernance et la gestion des Ressources informationnelles (Loi 133) va sûrement accentuer davantage la question d’efficacité des projets publics en TI. Chez nos voisins du Sud, dans un plan de réforme de la gestion des TI du gouvernement fédéral américain, le Dirigeant principal des technologies de l’information (CIO) du gouvernement a mis l'accent sur la «modularité» de projets, parmi les 25 points identifiés, ce qui permettrait de diminuer la durée des projets. Il est allé si loin qu’il a même limité la durée des projets à 12 mois, avec une cible de 6 mois. Alors, les choses bougent et il nous reste à voir s’il s’agit d’un véritable virage dans la gestion de projets publics.  

Y a-t-il encore une place pour les mégaprojets ?

Finalement, la question à se poser devient "est-il encore possible de bien réaliser un grand projet informatique"? La réponse est certainement affirmative. Il y a des organisations qui ont acquis beaucoup d’expertise dans les grands projets informatiques et qui les réalisent de façon très efficace et avec la valeur significative attendue par l’organisation. Cependant, à mon avis, au lieu de concentrer leurs efforts uniquement sur comment mieux faire les grands projets, les organisations devraient plutôt repenser fondamentalement leurs approches de planification et de choix de projets et commencer à prendre un virage vers les projets de petite et moyenne envergure. Ces projets sont moins risqués, livrent les résultats plus rapidement et contribuent plus de valeur à l’organisation. La solution réside donc dans la capacité de l’organisation de bien planifier le portefeuille de projets et de choisir les projets qui peuvent rapidement apporter les bénéfices avec un minimum de risque. Et les grands projets? On ne peut pas les éviter, mais il faut qu’ils deviennent l’exception plutôt que la pratique courante.

Asset 7